ES2814877T3 - Protección de seguridad de aplicaciones de dispositivos móviles basada en personalización y vinculación segura de dominios de código - Google Patents

Protección de seguridad de aplicaciones de dispositivos móviles basada en personalización y vinculación segura de dominios de código Download PDF

Info

Publication number
ES2814877T3
ES2814877T3 ES16178926T ES16178926T ES2814877T3 ES 2814877 T3 ES2814877 T3 ES 2814877T3 ES 16178926 T ES16178926 T ES 16178926T ES 16178926 T ES16178926 T ES 16178926T ES 2814877 T3 ES2814877 T3 ES 2814877T3
Authority
ES
Spain
Prior art keywords
security
mobile device
code
personalization
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16178926T
Other languages
English (en)
Inventor
Lafuente Carlos Alberto Pérez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Afirma Consulting & Tech S L
Original Assignee
Afirma Consulting & Tech S L
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Afirma Consulting & Tech S L filed Critical Afirma Consulting & Tech S L
Application granted granted Critical
Publication of ES2814877T3 publication Critical patent/ES2814877T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/14Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/125Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Stored Programmes (AREA)
  • Telephone Function (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método asociado con uno o más proveedores de servicios y un proveedor de servicios de personalización en relación a la personalización de seguridad de una aplicación software de dispositivo móvil en un dispositivo móvil de un usuario, el método incluyendo: usando por el proveedor de servicios de personalización una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad que están almacenados en una o más memorias para generar usando uno o más dispositivos de procesamiento una aplicación software protegida de dispositivo móvil que es personalizada en términos de seguridad usando datos del registro de personalización de seguridad, la aplicación generada incluyendo varios dominios de código, relativos a los uno o más proveedores de servicios, donde uno o más primeros dominios de código son vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar los uno o más primeros dominios de código para operación regular; enviando la aplicación software protegida de dispositivo móvil en un estado de seguridad nopersonalizada desde el proveedor de servicios de personalización a un servidor de distribución, dicho estado deshabilitando los uno o más primeros dominios de código para operación regular, y la aplicación software protegida de dispositivo móvil siendo almacenada en una o más memorias del servidor de distribución; recibiendo desde el dispositivo móvil del usuario una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada; enviando datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario, a la aplicación software protegida de dispositivo móvil no personalizada en seguridad en el dispositivo móvil del usuario, los datos de personalización de seguridad habilitando en la aplicación al menos uno de los uno o más primeros dominios de código para operación regular.

Description

DESCRIPCIÓN
Protección de seguridad de aplicaciones de dispositivos móviles basada en personalización y vinculación segura de dominios de código
Ámbito técnico
Esta invención es relativa a métodos y aparatos para personalizar automáticamente en términos de seguridad aplicaciones software de dispositivos móviles, estando la personalización asociada a vinculación segura de dominios de código.
Antecedentes
En las tecnologías móviles actuales numerosas aplicaciones móviles son protegidas usando elementos seguros tales como tarjetas SIM, chips embebidos o tarjetas micro-SD. A pesar de que esos contenedores seguros ofrecen una alta resistencia a la manipulación, aspectos de control de negocio hacen que los proveedores de servicios busquen alternativas para proteger los activos sensibles (tales como claves y datos secretos) de sus aplicaciones móviles, y las propias aplicaciones móviles.
Dentro de dichas alternativas la ofuscación de código y la criptografía white box, en combinación con otras técnicas, son usadas para proteger aplicaciones software de dispositivos móviles. Idealmente, cada aplicación debería ser protegida de una forma personalizada, pero a veces dicha personalización puede introducir complejidad adicional en términos de instalación y gestión de la aplicación.
El arte previo revela métodos para generar automáticamente aplicaciones software protegidas de dispositivos móviles mediante el uso de software de ofuscación, en donde una aplicación software protegida resultante dada de dispositivo móvil puede ser diferente que cualquier otra en términos de parámetros de seguridad y/o reglas de ofuscación. Dentro de dichos métodos el(los)fichero(s) binario(s) de aplicación resultantes de una protección de seguridad dada serían diferentes que el(los) fichero(s) binario(s) de aplicación resultantes de una protección de seguridad diferente de la misma versión de la aplicación.
Sin embargo, los mercados más populares de distribución de aplicaciones software de dispositivos móviles (ej. Google Play Store o Apple Store) no están actualmente habilitados para distribuir diferentes ficheros(s) binarios/ejecutables para diferentes grupos de usuarios, en relación a una versión dada de una aplicación. El(los) fichero(s) binario(s) son los mismos para todos los usuarios de dispositivos móviles que descargan e instalan una versión dada de la aplicación.
Considerando las limitaciones anteriores, la distribución de dicho(s) fichero(s) binario(s) para diferentes grupos de usuarios puede requerir el uso de servidores de distribución de aplicaciones diferentes que los de un mercado de aplicaciones (ej. servidores del proveedor de servicios propietario de la aplicación). Esto puede impactar en usabilidad, y a veces puede incluso no estar permitido por el propietario del sistema operativo del dispositivo móvil.
Para evitar los referidos problemas, dentro de esta invención el fichero(s) binario(s) asociado a una versión dada de una aplicación es el mismo para todos los usuarios de dispositivos móviles, pero se aplica una personalización de seguridad a la aplicación software protegida de dispositivo móvil de tal forma que dicha personalización está asociada a procesos seguros de vinculación de dominios de código, de forma que se consigue un aumento notable de la protección de la aplicación software de dispositivo móvil en los dispositivos móviles de los usuarios.
Por tanto, esta nueva invención revela métodos relativos a aplicaciones software protegidas de dispositivos móviles que incluyen varios dominios de código, relativos a uno o varios proveedores de servicios, donde al menos parte de ellos están en un estado no-personalizado de seguridad que les deshabilita para operación normal cuando la aplicación es distribuida e instalada en un dispositivo móvil de usuario, y uno o varios de esos dominios de código son personalizados posteriormente en la aplicación software protegida de dispositivo móvil mediante métodos y técnicas de personalización de seguridad que los habilitan para operación normal y que están basados en vincular en términos de seguridad uno o más de los dominios de código con otros uno o más de los dominios de código.
Ventajosamente, estos métodos y técnicas permiten mejorar la protección de la aplicación en términos de proteger activos sensibles y procesos críticos de la aplicación de una forma personalizada, como se describe a continuación.
Resumen de la invención
Lo que se revela aquí son nuevos métodos y aparatos para personalizar una aplicación software de dispositivo móvil en términos de seguridad, donde uno o más primeros dominios de código son vinculados en términos de seguridad a uno o más segundos dominios de código a través de una personalización de seguridad que es requerida para habilitar los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones esto se consigue proporcionando un método asociado con uno o más proveedores de servicios y un proveedor de servicios de personalización en relación a la personalización de seguridad de una aplicación software de dispositivo móvil en un dispositivo móvil de un usuario, el método incluyendo:
usando por el proveedor de servicios de personalización una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad que están almacenados en una o más memorias para generar usando uno o más dispositivos de procesamiento una aplicación software protegida de dispositivo móvil que es personalizada en términos de seguridad usando datos del registro de personalización de seguridad, la aplicación generada incluyendo varios dominios de código, relativos a los uno o más proveedores de servicio, donde uno o más primeros dominios de código son vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar los uno o más primeros dominios de código para operación regular;
enviando la aplicación software protegida de dispositivo móvil en un estado de seguridad no-personalizada desde el proveedor de servicios de personalización a un servidor de distribución, dicho estado deshabilitando los uno o más primeros dominios de código para operación regular, y la aplicación software protegida de dispositivo móvil siendo almacenada en una o más memorias del servidor de distribución;
recibiendo desde el dispositivo móvil del usuario una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada;
enviando datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario, a la aplicación software protegida de dispositivo móvil no personalizada en seguridad en el dispositivo móvil del usuario, los datos de personalización de seguridad habilitando en la aplicación al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones el proveedor de servicios de personalización es uno de los uno o más proveedores de servicios.
Conforme a algunas implementaciones el habilitado de el al menos uno de los uno o más primeros dominios de código está asociado a uno o más parámetros de seguridad relativos al registro de personalización de seguridad de ciclo de vida, que son diferentes que los correspondientes del registro de personalización de seguridad.
Conforme a algunas implementaciones la personalización de seguridad asociada al registro de personalización de seguridad de ciclo de vida es relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código son recibidas desde el dispositivo móvil del usuario, cada solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida son enviados a la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular. Ventajosamente diferentes grupos de uno o más primeros dominios de código no-habilitados son personalizados en términos de seguridad en diferentes instantes temporales, por lo que un atacante necesitaría realizar diferentes ataques a cada aplicación software protegida de dispositivo móvil a lo largo de su ciclo de vida de personalización de seguridad para intentar gradualmente explotar la funcionalidad cubierta por cada uno o más primeros dominios de código que ya han sido habilitados para operación regular.
Conforme a algunas implementaciones al menos uno del otro uno o más primeros dominios de código está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados a una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a los uno o más primeros dominios de código.
Conforme a algunas implementaciones uno o más dispositivos de procesamiento hacen una aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad expirar si una solicitud para una personalización de seguridad de al menos otro uno o más primeros dominios de código es recibida más tarde que un periodo de tiempo predefinido después de que datos de personalización de seguridad relativos a una solicitud previa para una personalización de seguridad de al menos uno u otro diferente uno de los uno o más primeros dominios de código fue enviada a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada o parcialmente-personalizada. Limitando la ventana de tiempo permitida entre dos procesos diferentes de personalización parcial de seguridad de uno o más primeros dominios de código, activos sensibles gestionados por la aplicación entre una personalización de seguridad y otra posterior pueden ser mejor protegidos.
Conforme a algunas implementaciones los uno o más primeros/segundos dominios de código asociados en una o más memorias del proveedor de servicios de personalización a la aplicación software protegida de dispositivo móvil en un dispositivo móvil de un primer usuario son diferentes que los uno o más primeros/segundos dominios de código asociados en una o más memorias del proveedor de servicios de personalización a la aplicación software protegida de dispositivo móvil en un dispositivo móvil de un segundo usuario.
Conforme a algunas implementaciones datos de re personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida, o a otro registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario, son enviados a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad parcialmente-personalizada o personalizada, los datos de re personalización de seguridad son al menos parcialmente diferentes que los datos de personalización de seguridad y habilitan en la aplicación para operación regular al menos uno de los uno o más primeros dominios de código y/o al menos uno del otro uno o más primeros dominios de código.
Conforme a algunas implementaciones al menos uno del otro uno o más primeros dominios de código está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código a través de la re personalización de seguridad, dicha re personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en el uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados a una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a los uno o más primeros dominios de código.
Conforme a algunas implementaciones uno o más primeros dominios de código asociados a un primer proveedor de servicios pueden ser habilitados para operación regular por el proveedor de servicios de personalización independientemente de la habilitación para operación regular de otros uno o más primeros dominios de código asociados a un segundo proveedor de servicios.
Conforme a algunas implementaciones hay un método asociado con el uso de un dispositivo móvil de un usuario en relación a la personalización de seguridad de una aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario, la aplicación software protegida de dispositivo móvil previamente generada por un proveedor de servicios de personalización en un estado de seguridad personalizada usando una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad, la aplicación protegida incluyendo varios dominios de código, relativos a uno o más proveedores de servicios, donde uno o más primeros dominios de código quedan vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad asociada al registro de personalización de seguridad, el método incluyendo:
solicitando desde el dispositivo móvil del usuario una aplicación software de dispositivo móvil a un servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada;
recibiendo desde el servidor de distribución y a continuación instalando por uno o más dispositivos de procesamiento en el dispositivo móvil la aplicación software protegida de dispositivo móvil en un estado de seguridad no-personalizada, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código están deshabilitados para operación regular;
enviando desde el dispositivo móvil del usuario una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estado en un estado de seguridad no-personalizada;
recibiendo datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no-personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones el habilitado de el al menos uno de los uno o más primeros dominios de código está asociado a uno o más parámetros de seguridad relativos al registro de personalización de seguridad de ciclo de vida, que son diferentes que los correspondientes del registro de personalización de seguridad.
Conforme a algunas implementaciones solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código son enviadas desde el dispositivo móvil del usuario al proveedor de servicios de personalización, cada solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario son recibidos en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
Conforme a algunas implementaciones al menos uno del otro uno o más primeros dominios de código está vinculado en términos de seguridad a uno o más primeros dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular están disponibles en una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a uno o más primeros dominios de código que han sido previamente habilitados para operación regular.
Conforme a algunas implementaciones una solicitud para una personalización de seguridad de al menos otro uno o más primeros dominios de código es enviada desde el dispositivo móvil del usuario al proveedor de servicios de personalización posteriormente a de un periodo de tiempo predefinido después de que datos de personalización de seguridad relativos a una solicitud previa para una personalización de seguridad de al menos uno u otro diferente uno de los uno o más primeros dominios de código fueran recibidos en la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada o parcialmentepersonalizada, y una notificación desde el proveedor de servicios de personalización indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado es recibida en el dispositivo móvil del usuario.
Conforme a algunas implementaciones el uno o más primeros dominios de código habilitados mediante primeros datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un primer usuario son diferentes que los uno o más primeros dominios de código habilitados mediante segundos datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un segundo usuario.
Conforme a algunas implementaciones los datos de personalización de seguridad recibidos en el dispositivo móvil de un primer usuario, los datos habilitando en la aplicación uno o más primeros dominios de código para operación regular y asociados a un primer registro de personalización de seguridad de ciclo de vida que incluye primeros parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código, son diferentes que los datos de personalización de seguridad recibidos en el dispositivo móvil de un segundo usuario, los datos habilitando en la aplicación uno o más primeros dominios de código para operación regular y asociados a un segundo registro de personalización de seguridad de ciclo de vida que incluye segundos parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código.
Conforme a algunas implementaciones datos de re personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida, o a otro registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario, son recibidos en la aplicación software protegida de dispositivo móvil estando en un estado de seguridad parcialmente-personalizada o personalizada, los datos de re personalización de seguridad son al menos parcialmente diferentes que los datos de personalización de seguridad y habilitan en la aplicación para operación regular al menos uno de los uno o más primeros dominios de código y/o al menos uno del otro uno o más primeros dominios de código.
Un medio leíble no transitorio de ordenador almacenando código leíble de programa de ordenador para causar un procesador de un dispositivo móvil de un usuario realizar un método asociado a la personalización de seguridad de una aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario, la aplicación software protegida de dispositivo móvil previamente generada por un proveedor de servicios de personalización en un estado de seguridad personalizada usando una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad, la aplicación protegida incluyendo varios dominios de código, relativos a uno o más proveedores de servicios, donde uno o más primeros dominios de código quedan vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad asociada al registro de personalización de seguridad, el método incluyendo:
solicitando desde el dispositivo móvil del usuario una aplicación software de dispositivo móvil a un servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada;
recibiendo desde el servidor de distribución y a continuación instalando por uno o más dispositivos de procesamiento en el dispositivo móvil la aplicación software protegida de dispositivo móvil en un estado de seguridad no-personalizada, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código están deshabilitados para operación regular;
enviando desde el dispositivo móvil del usuario una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estado en un estado de seguridad no-personalizada;
recibiendo datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no-personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones un medio leíble no transitorio de ordenador almacenando código leíble de programa de ordenador es provisto que causa el procesador enviando solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código desde el dispositivo móvil del usuario al proveedor de servicios de personalización, cada solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y recibiendo datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
Conforme a algunas implementaciones un dispositivo móvil de un usuario es provisto que está asociado con la personalización de seguridad de una aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario, la aplicación software protegida de dispositivo móvil previamente generada por un proveedor de servicios de personalización en un estado de seguridad personalizada usando una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad, la aplicación protegida incluyendo varios dominios de código, relativos a uno o más proveedores de servicios, donde uno o más primeros dominios de código quedan vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad asociada al registro de personalización de seguridad, el dispositivo móvil incluyendo:
un medio de almacenamiento electrónico que almacena datos de personalización de seguridad; y
un procesador adaptado a:
solicitar una aplicación software de dispositivo móvil a un servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no personalizada;
recibir desde el servidor de distribución y a continuación instalar en el dispositivo móvil la aplicación software protegida de dispositivo móvil en un estado de seguridad no-personalizada, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código estas deshabilitados para operación regular;
enviar una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no personalizada;
recibir datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no-personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones el procesador está adaptado para enviar solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código desde el dispositivo móvil del usuario al proveedor de servicios de personalización, cada solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y para recibir datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
Breve descripción de los dibujos
La figura 1 es un diagrama esquemático ilustrando métodos y aparatos conforme a algunas implementaciones, relativas a uno o más proveedores de servicios y un proveedor de servicios de personalización en relación a la personalización de seguridad de una aplicación software de dispositivo móvil, en donde una descripción más detallada es provista en relación al proveedor de servicio 1 y al proveedor de servicios de personalización.
Las figuras 2.a a 2.l son diagramas esquemáticos ilustrando métodos y aparatos conforme a algunas implementaciones en relación a la personalización de seguridad de una aplicación software de dispositivo móvil. En particular:
- La figura 2.a ilustra registros de personalización de seguridad generados por el proveedor de servicios de personalización y es también relativa a la generación de una aplicación software protegida de dispositivo móvil personalizada en seguridad.
- La figura 2.b ilustra algunas implementaciones donde una aplicación software de dispositivo móvil ha sido desarrollada para realizar funciones asociadas a un proveedor de servicios que es la misma entidad que el proveedor de servicios de personalización.
- La figura 2.c ilustra algunas implementaciones de aplicar una protección de seguridad a funciones en primeros dominios de código, en el contexto de generar una aplicación software protegida de dispositivo móvil.
- La figura 2.d ilustra algunas implementaciones asociadas a la protección de al menos partes de parámetros de seguridad, reglas de ofuscación y redes de checksums en una parte de la base de datos de la aplicación que está asociada a un dominio de código dado, en el contexto de generar una aplicación software protegida de dispositivo móvil.
- La figura 2.e ilustra un conjunto de registros de personalización de seguridad con valores por defecto (/erróneos) que pueden ser usados para propósitos de test.
- La figura 2.f ilustra una personalización de seguridad que usa valores por defecto y escenarios de test.
- La figura 2.g ilustra algunas implementaciones asociadas a la protección de datos de personalización de seguridad asociados a la aplicación software protegida de dispositivo móvil instalada en el dispositivo móvil de un primer y de un segundo usuario.
- La figura 2.h ilustra algunas implementaciones donde el dispositivo móvil de un primer usuario almacena datos de personalización de seguridad que habilitan primeros dominios de código para operación regular.
- La figura 2.i ilustra algunas implementaciones donde el dispositivo móvil de un primer usuario almacena datos de personalización de seguridad que habilitan primeros dominios de código y otros primeros dominios de código para operación regular.
- La figura 2.j ilustra algunas implementaciones donde el dispositivo móvil de un segundo usuario almacena datos de personalización de seguridad que habilitan primeros dominios de código y otros primeros dominios de código para operación regular.
- La figura 2.k ilustra algunas implementaciones asociadas a la protección de datos de re personalización de seguridad asociados a la aplicación software protegida de dispositivo móvil instalada en el dispositivo móvil de un segundo usuario.
- La figura 2.l ilustra algunas implementaciones donde el dispositivo móvil de un segundo usuario almacena datos de re personalización de seguridad que habilitan primeros dominios de código y otros primeros dominios de código para operación regular.
La figura 3 es un diagrama esquemático ilustrando métodos y aparatos donde la aplicación software protegida de dispositivo móvil es relativa a varios proveedores de servicios y una arquitectura equivalente a la ilustrada en la figura 2.b es replicada en el código de aplicación para cada uno de los proveedores de servicios.
Descripción detallada
La figura 1 es un diagrama esquemático ilustrando métodos y aparatos conforme a algunas implementaciones en relación a la personalización de seguridad de una aplicación software de dispositivo móvil. En particular, la figura 1 ilustra un método asociado con uno o más proveedores de servicios (201, 202, 203 and 204) y un proveedor de servicios de personalización (100) en relación a la personalización de seguridad de una aplicación software de dispositivo móvil en un dispositivo móvil de un usuario (400).
La aplicación software de dispositivo móvil puede ser desarrollada de tal forma que partes de ella puedan realizar funciones asociadas a uno o más proveedores de servicios, otras partes puedan realizar funciones asociadas a otros uno o más proveedores de servicios, etc. También, diferentes partes de la aplicación software de dispositivo móvil constituyen diferentes dominios de código, cada uno agrupando una o más funciones de la aplicación software de dispositivo móvil que están asociadas a uno o más proveedores de servicios.
En esta invención se aplica personalización de seguridad a ciertos dominios de código, dicha personalización habilitándolos para operación regular, es decir que los habilita para realizar regularmente las funciones del dominio de código asociadas a los uno o más proveedores de servicios relacionados. Algunas de esas funciones pueden ser relativas a procesos de ciclo de vida de la aplicación software protegida de dispositivo móvil tales como procesos de registro de servicios, procesos de personalización, procesos de pago, procesos de autenticación, solicitudes de información, etc., tal y como se ilustra en la figura 1.
En consecuencia, algunos procesos pueden tener lugar entre el dispositivo móvil del usuario y un servidor de registro de servicios, un servidor de personalización, un terminal de transacciones, un servidor de autenticación, un terminal proxy, un servidor proxy, un servidor procesando una primera parte de una transacción, un servidor procesando procesos de ciclo de vida de aplicación, etc. Otras funciones pueden ser relativas por ejemplo a procesos locales realizados por la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario.
En la figura 1 se ilustran varios proveedores de servicios, particularmente el proveedor de servicios 1 (201), el proveedor de servicios 2 (202), el proveedor de servicios 3 (203) y el proveedor de servicios 4 (204). Los proveedores de servicios pueden ser autoridades de transporte, empresas de servicios de salud, proveedores de servicios de internet de las cosas, proveedores de servicios de localización y/o presencia, instituciones financieras, etc.
Conforme a algunas implementaciones el proveedor de servicios de personalización es uno de los uno o más proveedores de servicios. En un ejemplo particular el proveedor de servicios 1 es la misma entidad que el proveedor de servicios de personalización y los dominios de código y las funciones relativas en una aplicación software de dispositivo móvil están enteramente asociadas al proveedor de servicios 1.
En el paso (1) uno o más dispositivos de procesamiento dentro del sistema del proveedor de servicios de personalización genera un conjunto de registros de personalización de seguridad y los almacena en una base de datos (BD) asociada a aplicaciones software protegidas de dispositivo móvil. Conforme a algunas implementaciones al menos parte de los registros de personalización de seguridad son generados a partir de datos de entrada proporcionados al proveedor de servicios de personalización por uno o más proveedores de servicios (esta posibilidad es representada en la figura 1 como paso (0) y paso (0'), en referencia al proveedor de servicios 1 y al proveedor de servicios 3 respectivamente, donde los datos de entrada son recibidos en el módulo de personalización de seguridad) tal que el proveedor de servicios relacionado pueda después asociar una al menos parte de un registro de personalización de seguridad recibido desde el proveedor de servicios de personalización con los datos de entrada relacionados.
La figura 1 ilustra un ejemplo de registros de personalización de seguridad generados de la siguiente forma:
- un registro de personalización de seguridad de inicialización (RPS-I) que incluye un conjunto de subregistros de seguridad genérica RS1, RS2, RS3, SR4, ..., RSi, ..., RSn, y un conjunto de subregistros de personalización de seguridad RPS21, RPS31, RPS41, ..., RpSi1, ..., RPSn1;
- un conjunto de registros de personalización de seguridad de ciclo de vida adicionales asociados a los subregistros de seguridad genérica RS1 y RS2: RPS22, RPS23, ..., RPS2j, ..., RPS2N];
- un conjunto de registros de personalización de seguridad de ciclo de vida adicionales asociados a los subregistros de seguridad genérica RS1 y RS3: RPS32, RPS33, . , RPS3j, . , RPS3N];
- un conjunto de registros de personalización de seguridad de ciclo de vida adicionales asociados a los subregistros de seguridad genérica RSi y RS4: RPS42, RPS43, ..., RPS4j, ..., RPS4N];
- un conjunto de registros de personalización de seguridad de ciclo de vida adicionales asociados a los subregistros de seguridad genérica RS1 y RSi: RPSi2, RPSi3, ..., RPSy, ..., RPSín];
- un conjunto de registros de personalización de seguridad de ciclo de vida adicionales asociados a los subregistros de seguridad genérica RSi y RSn: RPSn2, RPSn3, ..., RPSny, ..., RPSnN];
En el paso (2) el proveedor de servicios de personalización utiliza una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad que están almacenados en una o más memorias para generar utilizando uno o más dispositivos de procesamiento una aplicación software protegida de dispositivo móvil que está personalizada en términos de seguridad utilizando datos del registro de personalización de seguridad. En un ejemplo particular el registro de personalización de seguridad es el registro de personalización de seguridad de inicialización (RPS-I) referido anteriormente.
Conforme a algunas implementaciones las una o más memorias y los uno o más dispositivos de procesamiento residen en uno o más servidores del proveedor de servicios de personalización.
Tal y como se ha descrito anteriormente la aplicación generada incluye varios dominios de código, relativos a los uno o más proveedores de servicios, donde uno o más primeros dominios de código están vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar los uno o más primeros dominios de código para operación regular.
La aplicación puede ser testeada con objeto de verificar que la personalización de seguridad habilita los uno o más dominios de código para operación regular (ej. usando un emulador de dispositivo móvil que sea parte del software de protección de seguridad). En el paso (3) la aplicación software protegida de dispositivo móvil es almacenada en la base de datos (BD) asociada a aplicaciones software protegidas de dispositivo móvil, en relación a los datos de personalización de seguridad que habilitan los uno o más primeros dominios de código para operación regular y a los registros de personalización de seguridad (incluyendo RPS-I)
Posteriormente, en el paso (4) el módulo de personalización de seguridad obtiene usando uno o más dispositivos de procesamiento la aplicación software protegida de dispositivo móvil de la base de datos.
Conforme a algunas implementaciones la aplicación protegida es obtenida sin ningún dato asociado a la personalización de seguridad que habilita los uno o más primeros dominios de código para operación regular, por lo que la aplicación obtenida es una aplicación software protegida de dispositivo móvil no personalizada en seguridad. La aplicación software protegida de dispositivo móvil no personalizada en seguridad está en un estado de personalización de seguridad pendiente, dicho estado de personalización de seguridad pendiente deshabilitando los uno o más primeros dominios de código para operación regular.
En el paso (5) la aplicación software protegida de dispositivo móvil es enviada en un estado de seguridad nopersonalizada desde el proveedor de servicios de personalización a un servidor de distribución de una entidad a cargo de distribuir la aplicación y dicha aplicación es almacenada en una o más memorias del servidor de distribución de dicha entidad. Como se ilustra en la figura 1, conforme a algunas implementaciones el servidor de distribución es relativo a uno o más de los servidores asociados a un mercado de distribución de aplicaciones o a una tienda de aplicaciones tales como Google Play Store o Apple Store.
En el paso (6) tras una interacción por parte del usuario (300) hay una solicitud desde el dispositivo móvil del usuario de una aplicación software de dispositivo móvil al servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada. Como puede ser bien entendido por aquellos expertos en la técnica, otros servidores pueden estar involucrados en recibir la solicitud desde el dispositivo móvil del usuario y/o en distribuir la aplicación al dispositivo móvil del usuario, pero independientemente de la arquitectura de servidores de la entidad que distribuye aplicaciones a dispositivos móviles, la solicitud de esta invención esta orientada a obtener la aplicación software protegida de dispositivo móvil no personalizada en seguridad desde el referido servidor de distribución, para distribución al dispositivo móvil del usuario.
En el paso (7) el dispositivo móvil del usuario recibe desde el servidor de distribución y a continuación instala mediante una o más dispositivos de procesamiento en el dispositivo móvil la aplicación software protegida de dispositivo móvil no personalizada en seguridad, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código están deshabilitados para operación regular.
Como se describe a continuación, conforme a algunas implementaciones el dispositivo móvil del usuario se usa en relación a la personalización de seguridad de la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario.
En el paso (8) el dispositivo móvil del usuario envía una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estando en un estado de seguridad nopersonalizada.
En el paso (9) el proveedor de servicios de personalización recibe la solicitud desde el dispositivo móvil del usuario y en el paso (10) uno o más dispositivos de procesamiento del proveedor de servicios de personalización asigna un registro de personalización de seguridad de ciclo de vida al dispositivo móvil del usuario en relación a la aplicación software protegida de dispositivo móvil. Conforme a algunas implementaciones el registro de personalización de seguridad de ciclo de vida asignado en este paso por el módulo de personalización de seguridad es diferente (ej. RPS33) que el registro de personalización de seguridad usado cuando se generó la aplicación software de dispositivo móvil personalizada en seguridad (RPS-I en el ejemplo de arriba). Todavía en el paso (10) la asignación del registro de personalización de seguridad de ciclo de vida al dispositivo móvil del usuario y a la aplicación software protegida de dispositivo móvil es almacenada en la base de datos asociada a aplicaciones software protegidas de dispositivo móvil.
En el paso (11) al menos parte de los datos del registro de personalización de seguridad de ciclo de vida asignado, y la asociación al dispositivo móvil del usuario y a la aplicación software protegida de dispositivo móvil, puede ser enviada al proveedor de servicios correspondiente tal que este pueda posteriormente usar al menos parte de estos en el contexto de ciertos procesos de ciclo de vida de la aplicación software protegida de dispositivo móvil (la figura 1 ilustra un ejemplo donde dichos datos son enviados al proveedor de servicios 1).
En el paso (12) datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida asignado son enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario. En particular, datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario son enviados a la aplicación software protegida de dispositivo móvil no personalizada en seguridad en el dispositivo móvil del usuario, los datos de personalización de seguridad habilitando en la aplicación al menos uno de los uno o más primeros dominios de código para operación regular.
En el paso (13) el dispositivo móvil del usuario recibe los datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, lo datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones el habilitado de el al menos uno de los uno o más primeros dominios de código está asociado a uno o más parámetros de seguridad relativos al registro de personalización de seguridad de ciclo de vida, que son diferentes que los correspondientes del registro de personalización de seguridad.
Ventajosamente, después de que la personalización de seguridad anterior haya sido realizada, los referidos al menos uno de los uno o más primeros dominios de código pueden ser usados para realizar regularmente las funciones asociadas de ciclo de vida de la aplicación software protegida de dispositivo móvil.
Conforme a algunas implementaciones diferentes grupos de uno o más primeros dominios de Código nohabilitados son personalizados en términos de seguridad en diferentes instantes temporales. Esta aproximación incrementa la seguridad de la aplicación software protegida de dispositivo móvil. Los pasos (14a, 15a y 16a) representan solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código, enviadas desde el dispositivo móvil del usuario al proveedor de servicios de personalización.
Dentro de estas implementaciones, cada solicitud del dispositivo móvil del usuario es lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular.
En el paso (14a) una solicitud sucesiva es enviada desde el dispositivo móvil del usuario al proveedor de servicios de personalización y en el paso (14b) el proveedor de servicios de personalización recibe la solicitud sucesiva desde el dispositivo móvil del usuario, y uno o más dispositivos de procesamiento del proveedor de servicios de personalización obtiene en el paso (14c) datos de personalización de seguridad del registro de personalización de seguridad de ciclo de vida previamente asignado al dispositivo móvil del usuario.
En el paso (14d) los datos de personalización de seguridad del registro de personalización de seguridad de ciclo de vida previamente asignado al dispositivo móvil del usuario son enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario. En particular, datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida son enviados a la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad.
En el paso (14e) el dispositivo móvil del usuario recibe del proveedor de servicios de personalización los datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
Los procesos asociados a los pasos 15b, 15c, 15d y 15e serán similares a aquellos ya descritos en relación a 14a, 14b, 14c, 14d y 14e, pero ahora en relación a la solicitud sucesiva 15a y a la habilitación en la aplicación para operación regular de el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular (15a).
También, los procesos asociados a los pasos 16b, 16c, 16d y 16e serán similares a aquellos ya descritos arriba en relación a 14a, 14b, 14c, 14d y 14e (o a 15a, 15b, 15c, 15d y 15e) pero ahora en relación a la solicitud sucesiva 16a y a la habilitación en la aplicación para operación regular de el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular (16a).
Conforme a algunas implementaciones al menos uno del otro uno o más primeros dominios de código está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular. Más allá, conforme a algunas implementaciones al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados a una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a los uno o más primeros dominios de código.
Una vez que los datos de personalización de seguridad son recibidos y almacenados en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, el al menos uno del otro uno o más primeros dominios de código queda vinculado en la aplicación en términos de seguridad al uno o más primeros dominios de código mediante dicha personalización de seguridad que es relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular. Conforme a algunas implementaciones dichos parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código han sido recibidos en la aplicación y están disponibles en una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a uno o más primeros dominios de código que han sido previamente habilitados para operación regular.
Conforme a algunas implementaciones uno o más dispositivos de procesamiento en el sistema del proveedor de servicios de personalización hacen una aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad expirar si una solicitud para una personalización de seguridad de al menos otro uno o más primeros dominios de código es recibida más tarde que un periodo de tiempo predefinido después de que datos de personalización de seguridad relativos a una solicitud previa para una personalización de seguridad de al menos uno u otro diferente uno de los uno o más primeros dominios de código fueran enviados a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada o parcialmente-personalizada. Esta aproximación aumenta aún más la seguridad de la aplicación software protegida de dispositivo móvil.
Conforme a algunas implementaciones, una notificación desde el proveedor de servicios de personalización indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado es enviada al dispositivo móvil del usuario y recibida en el dispositivo móvil del usuario.
En un ejemplo particular los procesos incluyendo hasta el paso 13 ya han sido realizados por lo que la aplicación software protegida de dispositivo móvil está en un estado de seguridad parcialmente personalizada. Como se ha descrito anteriormente, en el paso (14a) una solicitud sucesiva es enviada desde el dispositivo móvil del usuario y recibida en el paso (14b) por el proveedor de servicios de personalización. Dentro de este ejemplo, en el paso (14c), previamente a obtener datos de personalización de seguridad del registro de personalización de seguridad de ciclo de vida previamente asignado al dispositivo móvil del usuario, uno o más dispositivos de procesamiento del proveedor de servicios de personalización verifican si la solicitud ha sido recibida (paso 14b) más tarde que un periodo de tiempo predefinido después de que datos de personalización de seguridad fueran enviados a la aplicación software protegida de dispositivo móvil en el paso (12).
Si la solicitud ha sido recibida más tarde que dicho periodo de tiempo predefinido, entonces la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad asociada al dispositivo móvil del usuario expira en el sistema del proveedor de servicios de personalización. Conforme a algunas implementaciones, el proveedor de servicios de personalización notifica (no ilustrado en la figura 1) a uno o más proveedores de servicios acerca del estado de expiración de la aplicación software protegida de dispositivo móvil asociada al dispositivo móvil del usuario. También, una notificación indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado es enviada al dispositivo móvil del usuario y recibida en el dispositivo móvil del usuario.
En otro ejemplo particular los procesos incluyendo hasta el paso 14e ya han sido realizados por lo que la aplicación software protegida de dispositivo móvil está en un estado de seguridad parcialmente personalizada. En el paso (15a) una solicitud sucesiva es enviada desde el dispositivo móvil del usuario y recibida en el paso (15b) por el proveedor de servicios de personalización. Dentro de este ejemplo, en el paso (15c), previamente a obtener datos de personalización de seguridad del registro de personalización de seguridad de ciclo de vida previamente asignado al dispositivo móvil del usuario, uno o más dispositivos de procesamiento del proveedor de servicios de personalización verifican si la solicitud ha sido recibida (paso 15b) más tarde que un periodo de tiempo predefinido después de que datos de personalización de seguridad fueran enviados a la aplicación software protegida de dispositivo móvil en el paso (14d).
Si la solicitud ha sido recibida más tarde que dicho periodo de tiempo predefinido, entonces la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad asociada al dispositivo móvil del usuario expira en el sistema del proveedor de servicios de personalización. Conforme a algunas implementaciones, el proveedor de servicios de personalización notifica (no ilustrado en la figura 1) a uno o más proveedores de servicios acerca del estado de expiración de la aplicación software protegida de dispositivo móvil asociada al dispositivo móvil del usuario. Complementariamente, una notificación indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado puede ser enviada al dispositivo móvil del usuario.
Conforme a algunas implementaciones los uno o más primeros/segundos dominios de código asociados en una o más memorias del proveedor de servicios de personalización a la aplicación software protegida de dispositivo móvil en un dispositivo móvil de un primer usuario son diferentes que los uno o más primeros/segundos dominios de código asociados en una o más memorias del proveedor de servicios de personalización a la aplicación software protegida de dispositivo móvil en un dispositivo móvil de un segundo usuario. En una implementación particular cada registro de personalización de seguridad de ciclo de vida está ya asociado a un conjunto de uno o más primeros y segundos dominios de código en la fase de generación (en un ejemplo particular: RPS33 está asociado a los dominios de código 1, 3/1 and 3/2; y RPS42 está asociado a los dominios de código 1, 4/1 and 4/2) tal que cuando un registro de personalización de seguridad de ciclo de vida es asignado a un dispositivo móvil de un usuario dado en el paso (10) la asociación al correspondiente conjunto de uno o más primeros y segundos dominios de código es heredada.
Conforme a algunas implementaciones el uno o más primeros dominios de código habilitados mediante primeros datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un primer usuario son diferentes que los uno o más primeros dominios de código habilitados mediante segundos datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un segundo usuario.
Conforme a algunas implementaciones los datos de personalización de seguridad recibidos en el dispositivo móvil de un primer usuario,
Conforme a algunas implementaciones los datos de personalización de seguridad recibidos en el dispositivo móvil de un primer usuario, los datos habilitando en la aplicación uno o más primeros dominios de código para operación regular y asociados a un primer registro de personalización de seguridad de ciclo de vida que incluye primeros parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código, son diferentes que los datos de personalización de seguridad recibidos en el dispositivo móvil de un segundo usuario, los datos habilitando en la aplicación uno o más primeros dominios de código para operación regular y asociados a un segundo registro de personalización de seguridad de ciclo de vida que incluye segundos parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código.
Conforme a algunas implementaciones la aplicación software protegida de dispositivo móvil puede ser re personalizada a lo largo de su ciclo de vida.
La figura 1 ilustra una implementación en donde uno o más dispositivos de procesamiento dentro del sistema del proveedor de servicios de personalización obtiene en el paso (17) datos de re personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida, o a otro registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario, desde la base de datos asociada a la aplicación software protegida de dispositivo móvil.
Los referidos datos de re personalización de seguridad son enviados en el paso (18) a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad parcialmente personalizada o personalizada, los datos de re personalización de seguridad son al menos parcialmente diferentes que los datos de personalización de seguridad.
En el paso (19) los datos de re personalización de seguridad son recibidos en la aplicación software protegida de dispositivo móvil estando en un estado de seguridad parcialmente personalizada o personalizada, y habilitan en la aplicación para operación regular al menos uno de los uno o más primeros dominios de código y/o al menos uno del otro uno o más primeros dominios de código. Ventajosamente, en esta invención al menos parte de la protección de seguridad puede ser renovada de vez en cuando a bajo ciertas circunstancias.
Conforme a algunas implementaciones al menos uno del otro uno o más primeros dominios de código está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código a través de la re personalización de seguridad, dicha re personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en el uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular. Adicionalmente, conforme a algunas implementaciones al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados a una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a los uno o más primeros dominios de código.
Las figuras 2.a a 2.l son diagramas esquemáticos ilustrando métodos y aparatos conforme a algunas implementaciones en relación a la personalización de seguridad de una aplicación software de dispositivo móvil. Por simplicidad, estos diagramas ilustran métodos asociados con un proveedor de servicios y un proveedor de servicios de personalización en relación a la personalización de seguridad de una aplicación software de dispositivo móvil en un dispositivo móvil de un usuario. Para mayor simplicidad, en la descripción de estos diagramas se considerará que el proveedor de servicios y el proveedor de servicios de personalización son la misma entidad (proveedor de servicios 1 en el contexto de las figuras 2.a a 2.l).
La figura 2.a ilustra un ejemplo de registros de personalización de seguridad generados por el proveedor de servicios de personalización. Como ya se ha referido en relación al paso (1) de la figura 1, uno o más dispositivos de procesamiento dentro del sistema del proveedor de servicios de personalización genera un conjunto de registros de personalización de seguridad.
En el ejemplo ilustrado en la figura 2.a hay un registro de personalización de seguridad de inicialización (RPS-I) que incluye un conjunto de subregistros de seguridad genérica RS1, RS2, RS3, RS4, ..., RSi, ..., RSn, y un conjunto de subregistros de personalización de seguridad RPS21, RPS31, RPS41, ..., RPSM, ..., RPSn1 donde: - RSi and RS2 are associated to RPS21;
- RS1 and RS3 are associated to RPS31;
- RS1 and RS4 are associated to RPS41;
- RS1 and RSi are associated to RPSM;
- RSi and RSn are associated to RPSni;
Dentro de este ejemplo los subregistros de seguridad genérica y los subregistros de personalización de seguridad incluyen datos asociados a parámetros de seguridad (ps), reglas de ofuscación (ro) y redes de checksums (ch). En otro ejemplo particular los subregistros de personalización de seguridad incluyen datos asociados a parámetros de seguridad (ps) y/o reglas de ofuscación (ro) y/o redes de checksums (ch).
La figura 2.a también ilustra diferentes conjuntos de registros de personalización de seguridad de ciclo de vida adicionales de la siguiente forma:
- un conjunto de registros de personalización de seguridad de ciclo de vida asociados a los subregistros de seguridad genérica RSi y RS2: RPS22, RPS23, ..., RPS2j, ..., RPS2N];
- un conjunto de registros de personalización de seguridad de ciclo de vida asociados a los subregistros de seguridad genérica RSi y RS3: RPS32, RPS33, ..., RPS3j, ..., RPS3N];
- un conjunto de registros de personalización de seguridad de ciclo de vida asociados a los subregistros de seguridad genérica RSi y RS4: RPS42, RPS43, ..., RPS4j, ..., RPS4N];
- un conjunto de registros de personalización de seguridad de ciclo de vida asociados a los subregistros de seguridad genérica RSi y RSi: RPSi2, RPSí3, ..., RPSy, ..., RPSín];
- un conjunto de registros de personalización de seguridad de ciclo de vida asociados a los subregistros de seguridad genérica RSi y RSn: RPSn2, RPSn3, ..., RPSnj, ..., RPSnN];
Dentro de este ejemplo los registros de personalización de seguridad de ciclo de vida incluyen datos asociados a parámetros de seguridad (ps), reglas de ofuscación (ro) y redes de checksums (ch). En otro ejemplo particular los registros de personalización de seguridad de ciclo de vida incluyen datos asociados a parámetros de seguridad (ps) y/o reglas de ofuscación (ro) y/o redes de checksums (ch).
La figura i ilustra el uso por el proveedor de servicios de personalización de una aplicación software de dispositivo móvil, un registro de personalización de seguridad (RPS-I en el ejemplo de la figura i ) y software de protección de seguridad para generar una aplicación software protegida de dispositivo móvil que está personalizada en términos de seguridad utilizando datos del registro de personalización de seguridad.
Conforme a algunas implementaciones se calculan parámetros de seguridad dentro del sistema del proveedor de servicios de personalización. En un ejemplo particular los parámetros de seguridad son calculados en el módulo de personalización de seguridad y son almacenados en los registros de personalización de seguridad. La figura 2.a ilustra los parámetros de seguridad (ps) calculados almacenados en los correspondientes registros de personalización de seguridad (RPS-I, RPS22, . , RPS2N, . , RPSnN)
Conforme a algunas implementaciones parámetros de seguridad del registro de personalización de seguridad (RPS-I en el ejemplo) son usados por el software de protección de seguridad para proteger ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones al menos parte de los parámetros de seguridad del registro de personalización de seguridad son embebidos por el software de protección de seguridad en el código de aplicación (ej. ps3-RSi). Conforme a algunas implementaciones, parte de al menos un parámetro de seguridad dado del registro de personalización de seguridad es embebido por el software de protección de seguridad en el código de aplicación (ej. psia-RS2) y otra parte es almacenada en la base de datos de la aplicación software protegida de dispositivo móvil (ej. psib-RPS2i).
i5
Conforme a algunas implementaciones al menos parte de los parámetros de seguridad del registro de personalización de seguridad (RPS-I en el ejemplo) son ofuscados por el software de protección de seguridad en el código de la aplicación software de dispositivo móvil (ej. ps3-RS1), usando reglas de ofuscación incluidas en el registro de personalización de seguridad (ej. ro3-RS1). Conforme a algunas implementaciones, parte de al menos un parámetro de seguridad dado del registro de personalización de seguridad es ofuscado por el software de protección de seguridad en el código de aplicación (ej. ps1a-RS2) y otra parte es almacenada en un formato ofuscado en la base de datos de la aplicación software protegida de dispositivo móvil (ej. psib-RPS2i), usando reglas de ofuscación incluidas en el registro de personalización de seguridad (ej. una parte de ro3-RS1 y roib-RPS21).
Conforme a algunas implementaciones una aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un usuario es personalizada con al menos parte de al menos un parámetro de seguridad dado, dicha parte incluida en un registro de personalización de seguridad de ciclo de vida (ej. psib-RPS33 incluido en RPS33) y siendo almacenada durante un proceso de personalización de seguridad en la base de datos de la aplicación software protegida de dispositivo móvil, el parámetro de seguridad protegiendo ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones al menos parte de al menos un parámetro de seguridad dado, dicha parte incluida en un registro de personalización de seguridad de ciclo de vida (ej. psib-RPS33 incluido en RPS33), es almacenada durante un proceso de personalización de seguridad en un formato ofuscado en la base de datos de una aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un usuario, usando reglas de ofuscación que están parcialmente incluidas en el registro de personalización de seguridad (ej. parte de ro3-RS1) y parcialmente incluidas en el registro de personalización de seguridad de ciclo de vida (ej. parte de roib-RPS33), el parámetro de seguridad protegiendo ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones redes de checksums son calculadas dentro de sistema del proveedor de servicios de personalización. En un ejemplo particular las redes de checksums son calculadas por el software de protección de seguridad y son almacenadas en los registros de personalización de seguridad. La figura 2.a ilustra las redes de checksums (ch) calculadas almacenadas en los correspondientes registros de personalización de seguridad (RPS-I, RPS22, ... , RPS2N, ... , RPSnN).
Conforme a algunas implementaciones al menos parte de los checksums de las redes de checksums del registro de personalización de seguridad (RPS-I en el ejemplo) son calculados como checksums del código de aplicación (ej. ch3-RSi). Conforme a algunas implementaciones al menos parte de los checksums de las redes de checksums del registro de personalización de seguridad son calculados como checksums del código de la aplicación y/o de parámetros de seguridad del registro de personalización de seguridad (ej. ch3-RS2 calculado usando una parte dada del código de la aplicación y pss-RSi; o ej. chib-RPS2i calculado usando ps3-RS2i o ej. chib-RPS21 calculado usando psib-RPS2i).
Conforme a algunas implementaciones redes de checksums del registro de personalización de seguridad (RPS-I en el ejemplo) son usadas por el software de protección de seguridad para proteger ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones al menos parte de las redes de checksums del registro de personalización de seguridad son embebidas por el software de protección de seguridad en el código de la aplicación (ej. ch3-RSi). Conforme a algunas implementaciones, parte de al menos un checksum dado del registro de personalización de seguridad es embebido por el software de protección de seguridad en el código de la aplicación (ej. chia-RS2) y otra parte es almacenada en la base de datos de la aplicación software protegida de dispositivo móvil (ej. chib-RPS2i).
Conforme a algunas implementaciones al menos parte de las redes de checksums del registro de personalización de seguridad (RPS-I en el ejemplo) son ofuscadas por el software de protección de seguridad dentro del código de la aplicación software de dispositivo móvil (ej. ch^RSi), usando reglas de ofuscación incluidas en el registro de personalización de seguridad (ej. ro3-RSi). Conforme a algunas implementaciones, parte de al menos un checksum dado del registro de personalización de seguridad es ofuscada por el software de protección de seguridad en el código de la aplicación (ej. chia-RS2) y otra parte es almacenada en un formato ofuscado en la base de datos de la aplicación software protegida de dispositivo móvil (ej. chib-RPS2i), usando reglas de ofuscación incluidas en el registro de personalización de seguridad (ej. una parte de ro3-RSi and roib-RPS21).
Conforme a algunas implementaciones una aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un usuario es personalizada con al menos parte de al menos un checksum dado, dicha parte incluida en un registro de personalización de seguridad de ciclo de vida (ej. ch1b-RPS33 incluido en RPS33) y siendo almacenada durante un proceso de personalización de seguridad en la base de datos de la aplicación software protegida de dispositivo móvil, el checksum protegiendo ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones al menos parte de al menos un checksum dado, dicha parte incluida en un registro de personalización de seguridad de ciclo de vida (ej. ch1b-RPS33 incluido en RPS33), es almacenado durante un proceso de personalización de seguridad en un formato ofuscado en la base de datos de una aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un usuario, usando reglas de ofuscación que están parcialmente incluidas en el registro de personalización de seguridad (ej. ro3-RS1) y parcialmente incluidas en el registro de personalización de seguridad de ciclo de vida (ron>RPS33), el checksum protegiendo ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones un proceso de ofuscación es aplicado dentro del sistema del proveedor de servicios de personalización al código de la aplicación, y/o a parámetros de seguridad del registro de personalización de seguridad que están al menos parcialmente embebidos en el código de la aplicación y/o que está parcialmente almacenados en la base de datos de la aplicación, y/o a checksums de las redes de checksums del registro de personalización de seguridad que están al menos parcialmente embebidos en el código de la aplicación y/o que están al menos parcialmente almacenados en la base de datos de la aplicación. En un ejemplo particular el referido proceso de ofuscación es aplicado por el software de protección de seguridad.
El proceso de ofuscación puede incluir una diversidad de técnicas de ofuscación bien conocidas tales como por ejemplo reemplazar una instrucción del código de la aplicación o un conjunto de instrucciones del código de aplicación con otra instrucción de código de aplicación o conjunto de instrucciones de aplicación con funcionalidad equivalente; cambiar el orden de instrucciones del código de la aplicación; cambiar el orden de funciones o bloques de instrucciones del código de la aplicación; cambiar la estructura de bucles; añadir saltos sin sentido; insertar datos o instrucciones de código de aplicación sin uso; entrelazar una o más secuencias de código de la aplicación; reordenar datos estáticos; reordenación de datos de tiempo de ejecución; encriptación de instrucciones de programa; encriptación de datos estáticos; reemplazar valores constantes con código de aplicación que genera el valor constante; mover datos estáticos o de tiempo de ejecución entre pilas, montones y registros; usar diferentes pilas; usar varios punteros de pila para la misma pila; hacer que el código de programa se auto modifique; mezclar datos (ej. parámetros de seguridad y/ checksums del código) con código de programa; asignar particiones de datos de seguridad, embebidas en diferentes partes del código de la aplicación; renombrar clases, funciones, o variables; renombrar ficheros o módulos. Como puede ser bien entendido por un experto en la técnica, la lista anterior no es exhaustiva y otras técnicas de ofuscación adicionales pueden ser también aplicadas a la aplicación software de dispositivo móvil sin alejarse del ámbito de esta invención. También, debe ser entendido que algunas de las técnicas pueden ser aplicadas más de una vez (eso es aplicar una o más técnicas de ofuscación a código y/o datos ya ofuscados) para conseguir un grado de ofuscación mayor.
Conforme a algunas implementaciones el proceso de ofuscación depende de un paso previo de calcular reglas de ofuscación del registro de personalización de seguridad (RPS-I en el ejemplo) que son usadas por el software de protección de seguridad para proteger ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones reglas de ofuscación son calculadas en el sistema del proveedor de servicios de personalización y son almacenadas en los registros de personalización de seguridad. En un ejemplo particular las reglas de ofuscación son calculadas por el software de protección de seguridad o en el módulo de personalización de seguridad. La figura 2.a ilustra las reglas de ofuscación (ro) calculadas almacenadas en los correspondientes registros de personalización de seguridad (RPS-I, RPS22, ... , RPS2N, ... , RPSnN).
Conforme a algunas implementaciones al menos parte de las reglas de ofuscación del registro de personalización de seguridad (RPS-I en el ejemplo) son calculadas en relación a la ofuscación del código de la aplicación (ej. ro3-RSi calculado en relación a la ofuscación de una parte dada del código de la aplicación). Conforme a algunas implementaciones al menos parte de las reglas de ofuscación del registro de personalización de seguridad son calculadas en relación a la ofuscación del código de la aplicación y/o de parámetros de seguridad del registro de personalización de seguridad que están al menos al menos parcialmente embebidos en el código de la aplicación y/o que están al menos parcialmente almacenados en la base de datos de la aplicación, y/o de checksums de las redes de checksums del registro de personalización de seguridad que están al menos parcialmente embebidos en el código de la aplicación y/o que están al menos parcialmente almacenados en la base de datos de la aplicación (ej. ro3-RS1 calculada en relación a la ofuscación de una parte dada del código de la aplicación y a la ofuscación de ps3-RS2y a la ofuscación de ch3-RS2; o ej. ro1brps31 calculada en relación a la ofuscación de psn>RPS31 y ch1b-RPS31).
Conforme a algunas implementaciones al menos parte de las reglas de ofuscación del registro de personalización de seguridad son embebidas por el software de protección de seguridad en el código de la aplicación (ej. ro1-RS1) durante un proceso de ofuscación. Conforme a algunas implementaciones, durante un proceso de ofuscación parte de al menos una regla de ofuscación dada del registro de personalización de seguridad es embebida por el software de protección de seguridad en el código de la aplicación (ej. ro1a-RS4) y otra parte es almacenada en la base de datos de la aplicación software protegida de dispositivo móvil (ej. ro1brps41). Conforme a algunas implementaciones, la aplicación software protegida de dispositivo móvil es programada para usar al menos parte de las reglas de ofuscación embebidas/almacenadas para ejecutar correctamente instrucciones de código de la aplicación y/o para obtener/usar datos de la aplicación según definido.
Conforme a algunas implementaciones al menos parte de las reglas de ofuscación del registro de personalización de seguridad (RPS-I en el ejemplo) están ofuscadas en relación a otras reglas de ofuscación (ej. ro1b-RPS41 ofuscada en la aplicación software protegida de dispositivo móvil en relación a rom-RS1).
Conforme a algunas implementaciones una aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un usuario es personalizada con al menos parte de al menos una regla de ofuscación dada, dicha parte incluida en un registro de personalización de seguridad de ciclo de vida (ej. ro1b-RPS33 incluida en RPS33) y siendo almacenada durante un proceso de personalización de seguridad en la base de datos de la aplicación software protegida de dispositivo móvil, la regla de ofuscación protegiendo ciertos datos sensibles y/o procesos de / asociados a la aplicación software de dispositivo móvil.
Conforme a algunas implementaciones parte de al menos una regla de ofuscación dada, dicha parte incluida en un registro de personalización de seguridad de ciclo de vida (ej. ro2b-RPS33 incluida en RPS33), es almacenada durante un proceso de personalización de seguridad en un formato ofuscado en la base de datos de una aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un usuario, usando para la ofuscación al menos parte de otra regla de ofuscación dada (ej. ro2b-RPS33 ofuscada usando al menos parte de ro1a-RS3 and ro1b-RPS33).
La figura 2.b es relativa a algunas implementaciones donde una aplicación software de dispositivo móvil ha sido desarrollada para realizar funciones asociadas a un proveedor de servicios (proveedor de servicios 1 en el contexto de 2.a a 2.l) que es la misma entidad que el proveedor de servicios de personalización.
Conforme a algunas implementaciones, diferentes partes de la aplicación software de dispositivo móvil constituyen diferentes dominios de código, cada una agrupando una o más funciones de la aplicación software de dispositivo móvil que están asociadas al proveedor de servicios. La figura 2.b ilustra un ejemplo de una aplicación software de dispositivo móvil con los siguientes dominios de código y funciones asociadas al proveedor de servicios:
- Dominio de código 1 (DC1) incluyendo funciones (f1üC1 f2oC1, ...) de la aplicación software de dispositivo móvil;
- Dominio de código 2/1 (DC2/1) incluyendo funciones (f1oC2/1, f2oC2/1, ■■■) de la aplicación software de dispositivo móvil;
- Dominio de código 2/2 (DC2/2) incluyendo funciones (f1DC2/2, f2üC2/2, ...) de la aplicación software de dispositivo móvil;
- Dominio de código 3/1 (DC3/1) incluyendo funciones (f1DC3/1, f2DC3/1, ■■■) de la aplicación software de dispositivo móvil;
- Dominio de código 3/2 (DC3/2) incluyendo funciones (f1DC3/2, f2DC3/2, ...) de la aplicación software de dispositivo móvil;
- Dominio de código 4/1 (DC4/1) incluyendo funciones (f1DC4/1 f2DC4/1, ...) de la aplicación software de dispositivo móvil;
- Dominio de código 4/2 (DC4/2) incluyendo funciones (flüC4/2, f2DC4/2, ...) de la aplicación software de dispositivo móvil;
- Dominio de código i/1 (DCi/1) incluyendo funciones (f1 dci/i , f2oci/i, ...) de la aplicación software de dispositivo móvil;
- Dominio de código i/2 (DCi/2) incluyendo funciones (flDCi/2, f2DCi/2, ...) de la aplicación software de dispositivo móvil;
- Dominio de código n/1 (DCn/1) incluyendo funciones (flDCn/i, f2Dcn/i, ■■■) de la aplicación software de dispositivo móvil;
- Dominio de código n/2 (DCn/2) incluyendo funciones (flDcn/2, f2DCn/2, ...) de la aplicación software de dispositivo móvil;
Conforme a algunas implementaciones:
- Instrucciones de código de (flDC2/i, f2DC2/i, ...) en DC2/1 de la aplicación son respectivamente equivalentes en términos de funcionalidad que instrucciones de código de (fiDC3/i, f2DC3/i, ■■■) en DC3/ i de la aplicación;
- e instrucciones de código de (fiDC2/i, f2DC2/i ■ ■■) en DC2/ i de la aplicación, e instrucciones de código de ( f i dc3/i , f2DC3/i, ■ ) en DC3/ i de la aplicación, son cada una respectivamente equivalentes en términos de funcionalidad que instrucciones de código de (fiDC4/i, f2DC4/i, ■■■) en DC4/ i de la aplicación;
- e instrucciones de código de (fiDC2/i, f2DC2/i ■ ■■) en DC2/ i de la aplicación, e instrucciones de código de ( f i dc3/i , f2DC3/i, ■■■) en DC3/ i de la aplicación, ..., e instrucciones de código de (fiDCn-i/i, f2Dcn-i/i, ■■■) en D C n -i/i de la aplicación, son cada una respectivamente equivalentes en términos de funcionalidad que instrucciones de código de (fiDCn/i, f2Dcn/i, ■■■) en DCn/i de la aplicación;
- e instrucciones de código de (fiDC2/2, f2DC2/2, ...) en DC2/2 de la aplicación son respectivamente equivalentes en términos de funcionalidad que instrucciones de código de (fiDC3/2, f2DC3/2, ...) en DC3/2 de la aplicación;
- e instrucciones de código de (fiDC2/2, f2DC2/2...) en DC2/2 de la aplicación, e instrucciones de código de ( f i DC3/2, f2DC3/2, ■■■) en DC3/2 de la aplicación, son cada una respectivamente equivalentes en términos de funcionalidad que instrucciones de código de (fiDC4/2, f2DC4/2, ...) en DC4/2 de la aplicación;
- e instrucciones de código de (fiDC2/2, f2DC2/2...) en DC2/2 de la aplicación, e instrucciones de código de ( f i DC3/2, f2DC3/2, ■■■) en DC3/2 de la aplicación, ..., e instrucciones de código de (fiDCn-i/2, f2Dcn-i/2, ■■■) en D C n-i/2 de la aplicación, son cada una respectivamente equivalentes en términos de funcionalidad que instrucciones de código de (fiDCn/2, f2DCn/2, ...) en DCn/2 de la aplicación.
Por tanto, ventajosamente, en esas implementaciones la aplicación software de dispositivo móvil puede conseguir el mismo nivel de funcionalidad usando [(fiDCk/i, f2DCk/i, ■■■) en DCk/i y (fiDCk/2, f2DCk/2, ...) en Dck/2] que usando [ ( f idci/i , f2DCl/i, ■ ■■) en DCl/i y (fiDCl/2, f2DCl/2, ■ ■■) en DCl/2], k y l en el rango de 2 a n.
Como ya se ha mencionado en relación a la figura i, paso (2), el proveedor de servicios de personalización usa una aplicación software de dispositivo móvil, un registro de personalización de seguridad (ej. RPS-I) y software de protección de seguridad que están almacenados en una o más memorias para generar usando uno o más dispositivos de procesamiento una aplicación software protegida de dispositivo móvil que es personalizada en términos de seguridad usando datos del registro de personalización de seguridad.
La figura 2.b ilustra la protección de seguridad aplicada por el software de protección de seguridad a la aplicación software de dispositivo móvil en una implementación particular. El proceso de protección utiliza el registro de personalización de seguridad de inicialización (RPS-I) descrito en la figura 2.a para generar la aplicación software protegida de dispositivo móvil personalizada en seguridad.
En esta implementación los sub registros de seguridad genérica (RSi, RS2, RS3, RS4, ..., RSi, ..., RSn) y los sub registros de personalización de seguridad (RPS2i, RPS3i, RPS4i, ..., RPSM, ..., RPSni) del RPS-I incluyen parámetros de seguridad (ps), reglas de ofuscación (ro) y redes de checksums (ch), como los ilustrados en la figura 2.a. En esta implementación al menos parte de los checksums de las redes de checksums del registro de
i9
personalización de seguridad son calculados como checksums del código de la aplicación y de parámetros de seguridad del registro de personalización de seguridad.
En esta implementación un proceso de ofuscación es aplicado por el software de protección de seguridad al código de la aplicación software de dispositivo móvil, y a parámetros de seguridad del registro de personalización de seguridad que están al menos parcialmente embebidos en el código de la aplicación y/o que están al menos parcialmente almacenados en la base de datos de la aplicación por el software de protección de seguridad, y a checksums de las redes de checksums del registro de personalización de seguridad que están al menos parcialmente embebidos en el código de la aplicación y/o que están al menos parcialmente almacenados en la base de datos de la aplicación por el software de protección de seguridad. Los detalles son los siguientes:
- datos de RS1 son embebidos en el código de la aplicación de las funciones DC1(f1oci, f2oci, ■ ■■), y dicho código de la aplicación de las funciones DC1(f1oci, f2oci, ■ ■■), junto con los parámetros de seguridad [psirsi, ..., psr-Rsi] embebidos de RSi y las redes de checksums [chi-Rsi, ..., chr-Rsi] embebidas de R s i, son ofuscados usando al menos parte de las reglas de ofuscación [roi-Rsi, ..., ror-Rsi] embebidas. Por tanto, las funciones de DCi quedan protegidas a través de la ofuscación del código de las funciones de DCi y los parámetros de seguridad y redes de checksums de RSi embebidos, usando las reglas de ofuscación embebidas (ej. parte de ellas podrían estar protegidas mediante otras reglas de ofuscación). Dicha protección es ilustrada en la figura 2.b como PiRsi (protección de DCi usando RSi).
- Datos de RS2 son embebidos en el código de la aplicación de las funciones DC2/ i( f io c 2/i, f2oc2/i ■■■) y DC2/2( f i DC2/2, f2üC2/2, ■•■), y dicho código de la aplicación de las funciones DC2/ i( f io c 2/i, f2DC2/i, ■•■) y DC2/2( f i DC2/2, f2DC2/2, ■■■), junto con los parámetros de seguridad [psia-RS2, ■■■, psm-RS2] embebidos de RS2 y las redes de checksums [chia-RS2, ..., chm-RS2] embebidas de RS2, son ofuscados usando reglas de ofuscación (roia-RS2, ..., rom-RS2) que son al menos parcialmente embebidas en el código de la aplicación de las funciones DC2/i(fiD C2/i, f2DC2/i, ■■■) y DC2/2(fiDC2/2, f2DC2/2, ...) y que pueden también ser al menos parcialmente almacenadas en la parte correspondiente de la base de datos de la aplicación (ej. parte de roib-RPS2i y ro2b-rps2i). Por tanto las funciones DC2/i(fiD C2/i, f2DC2/i, ■■■) y DC2/2(fiDC2/2, f2DC2/2, ...) quedan protegidas a través de la ofuscación del código de las funciones DC2/i(fiD C2/i, f2DC2/i, ... )y DC2/2(fiDC2/2, f2cD2/2, ...) y los parámetros de seguridad y redes de checksums de RS2 embebidos, usando reglas de ofuscación que son al menos parcialmente embebidas en las funciones DC2/i(fiD C 2/i, f2DC2/i ...) y DC2/2( f i DC2/2, f2DC2/2, ■■ ) y que pueden ser al menos parcialmente almacenadas en la base de datos de la aplicación. Dicha protección es ilustrada en la figura 2.b como P2rs2 (protección de DC2/ i y DC2/2 basada en datos RS2 embebidos).
- Datos de RPS2 i son almacenados en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a DC2/ i and DC2/2 tal que el código de la aplicación de las funciones de DC2/ i y DC2/2 queda también protegido mediante los parámetros de seguridad, reglas de ofuscación y redes de checksums de RPS2 i . Dicha protección es ilustrada en la figura 2.b como P2rps2i (protección de DC2/ i y DC2/2 basada en datos almacenados de RPS2 i).
o [psia-RS2] y [psib-RPS2i] son las dos partes del mismo parámetro de seguridad, y en esta implementación [psia-RS2] es embebido en DC2/i(fiD C2/i, f2DC2/i, ■■■).
o [roia-RS2] y [roib-RPS2i] son las dos partes de la misma regla de ofuscación, y en esta implementación [roia-RS2] es embebida en DC2/i(fiD C2/i, f2DC2/i, ...).
o [chia-RS2] y [chib-RPS2i] son las dos partes de la misma red de checksums, y en esta implementación [chia-RS2] es embebido en DC2/i(fiD C2/i, f2DC2/i, ■■■).
o [ps2a-RS2] y [ps2b-RPS2i] son las dos partes del mismo parámetro de seguridad, y en esta implementación [ps2a-RS2] es embebido en DC2/2(fiDC2/2, f2DC2/2, ...).
o [ro2a-RS2] y [ro2b-RPS2i] son las dos partes de la misma regla de ofuscación, y en esta implementación [ro2a-RS2] es embebida en DC2/2(fiDC2/2, f2DC2/2, ■■■).
o [ch2a-RS2] y [ch2b-RPS2i] son las dos partes de la misma red de checksums, y en esta implementación [ch2a-RS2] es embebido en DC2/2(fiDC2/2, f2DC2/2, ■■■).
- datos de RSn son embebidos en el código de la aplicación de las funciones DCn/i(fiDcn/i, f2Dcn/i ■■■) y DCn/2( f i DCn/2, f2DCn/2, ■ ■■), y dicho código de la aplicación de las funciones DCn/i(fiDCn/i, f2DCn/i, ■■■) y DCn/2(f1 DCn/2, f2ücn/2, ...), junto con los parámetros de seguridad [psia-RSn, ..., pst-RSn] embebidos de RSn y las redes de checksums [chia-RSn, ..., cht-RSn] embebidas de RSn, son ofuscados usando reglas de ofuscación (roia-RSn, ..., rot-RSn) que son al menos parcialmente embebidas en el código de aplicación de las funciones DCn/1(flDcn/i, f2DCn/i, ...) y DCn/2 (flDCn/2, f2 DCn/2, ...) y que pueden también ser al menos parcialmente almacenadas en la parte correspondiente de la base de datos de la aplicación (ej. parte de roib-RPSni y ro2b-RPSni). Por tanto las funciones DCn/i(fiDCn/i, f2Dcn/i, ■■■) y DCn/2(ficDn/2, f2DCn/2, ...) quedan protegidas a través de la ofuscación del código de las funciones DCn/i(fiDCn/i, f2Dcn/i,...)y DCn/2 (fiDCn/2, f2DCn/2, . ) y los parámetros de seguridad y redes de checksums de RSn embebidos, usando reglas de ofuscación que son al menos parcialmente embebidas en las funciones DCn/i(fiDCn/i, f2Dcn/i ■■■) y DCn/2(fi DCn/2, f2 DCn/2, ■■■) y que pueden ser al menos parcialmente almacenadas en la base de datos de la aplicación. Dicha protección es ilustrada en la figura 2.b como PnRSn (protección de DCn/i y DCn/2 basada en datos RSn embebidos).
- Datos de RPSni son almacenados en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a DCn/i and DCn/2 tal que el código de la aplicación de las funciones de DCn/i y DCn/2 queda también protegido mediante los parámetros de seguridad, reglas de ofuscación y redes de checksums de RPSni. Dicha protección es ilustrada en la figura 2.b como PnRPSni (protección de DCn/i y DCn/2 basada en datos almacenados de RPSni).
o [psia-RSn] y [psib-RPSni] son las dos partes del mismo parámetro de seguridad, y en esta implementación [psia-RSn] es embebido en DCn/i(fiDCn/i, f2DCn/i, ...).
o [roia-RSn] and [roib-RPSni] son las dos partes de la misma regla de ofuscación, y en esta implementación [roia-RSn] es embebida en DCn/i(fiDCn/i, f2DCn/i, ■■■).
o [chia-RSn] and [chib-RPSni] son las dos partes de la misma red de checksums, y en esta implementación [chia-RSn] es embebido en DCn/i(fiDCn/i, f2DCn/i, ■■■).
o [ps2a-RSn] and [ps2b-RPSni] son las dos partes del mismo parámetro de seguridad, y en esta implementación [ps2a-RSn] es embebido en DCn/2(fiDCn/2, f2DCn/2, ...).
o [ro2a-RSn] and [ro2b-RPSni] son las dos partes de la misma regla de ofuscación, y en esta implementación [ro2a-RSn] es embebida en DCn/2(fiDCn/2, f2DCn/2, ...).
o [chi2a-RSn] and [chi2b-RPSni] son las dos partes de la misma red de checksums, y en esta implementación [chi2a-RSn] es embebido en DCn/2(fiDCn/2, f2DCn/2, ...).
Cuando instrucciones de código de una función o conjunto de funciones dadas de la aplicación software protegida de dispositivo móvil son ejecutadas por uno o más procesadores del dispositivo móvil, una operación regular de dicha función o conjunto de funciones puede requerir usar ciertos parámetros de seguridad, reglas de ofuscación y/o redes de checksums. Conforme a algunas implementaciones, al menos partes de esos parámetros de seguridad, reglas de ofuscación y/o redes de cheksums son para ser almacenados (/y ofuscados) en la base de datos de la aplicación, y si dichas partes no están disponibles en la correspondiente parte de la base de datos de la aplicación, o los valores no son correctos, entonces dicha función o conjunto de funciones no están habilitadas para operación regular, y el dominio(s) de código que incluye dicha función o conjunto de funciones esta (/están) también no habilitado para operación regular en relación a dicha función o conjunto de funciones.
Un intento de ejecutar instrucciones de código de una de esas funciones sin que los datos adecuados estén disponibles en la correspondiente parte de la base de datos de la aplicación puede causar una reacción de protección definida/esperada de la aplicación software protegida de dispositivo móvil (ej. la aplicación detiene su ejecución), puede causar un rechazo posterior por el proveedor de servicios de una solicitud de servicio recibida desde la aplicación software protegida de dispositivo móvil, etc., como consecuencia de la una o más funciones no estando habilitadas para operación regular.
La figura 2.c es relativa a algunas implementaciones de aplicar una protección de seguridad a funciones en DC2/i, DC2/2, DC3/i, DC3/2, ..., DCn/i y DCn/2, en el contexto de generar una aplicación software protegida de dispositivo móvil como la referida en la figura 2.b
En esta implementación, en términos de parámetros de seguridad de RS2 y RPS2i:
2 i
- [psia-RS2, PS3-RS2, PS4-RS2..., pSg-RS2] son embebidos (hard-coded) en el código de la aplicación de las funciones DC2/1(fi DC2/1, f2üC2/1, ...).
- [psia-RS2] y [psib-RPS2i] son las dos partes del mismo parámetro de seguridad. La figura 2.c ilustra que [psia-RS2] es embebido en el código de la aplicación de las funciones DC2/1(flDC2/ i , f2DC2/i, ...) y [psib-RPS21] es almacenado en una parte de la base de datos de la aplicación que está asociada a DC2/1. La figura 2.c también se refiere a la posibilidad de que [psib-RPS2i] sea almacenado en formato ofuscado como se describe en la figura 2.d.
- [ps2a-RS2, ps(g+i)-RS2 ps(g+2)-RS2..., psm-RS2] son embebidos en el código de la aplicación de las funciones DC2/2(f1 DC2/2, f2DC2/2, ■ ■■).
- [ps2a-RS2] y [ps2b-RPS2i] son las dos partes del mismo parámetro de seguridad. La figura 2.c ilustra que [ps2a-RS2] es embebido en el código de la aplicación de las funciones DC2 /2 (fiDC2/2 , f2 DC2/2, ...) y [ps2b-RPS21] es almacenado en una parte de la base de datos de la aplicación que está asociada a DC2/2. La figura 2.c también se refiere a la posibilidad de que [ps2b-RPS2 i] sea almacenado en formato ofuscado como se describe en la figura 2.d.
En términos de las redes de checksums de RS2 and RPS21:
- [chia-RS2, chi3-RS2, chi4-RS2..., chg-RS2] y [chib-RPS2 i] son calculados como checksums de partes del código de la aplicación de las funciones DC2 / 1 (fiDC2/i, f2 DC2/i, ...) y de al menos partes de uno o más parámetros de seguridad [psia-RS2, ps3-RS2, ps4-RS2 ..., psg-RS2] embebidos en el código de la aplicación de las funciones DC2/1(f1 DC2/1, f2DC2/1, ■ ■■).
- [chia-RS2, ch3-RS2, ch4-RS2 ..., chg-RS2] son embebidos (hard-coded) en el código de la aplicación de las funciones DC2/1(f1 DC2/1, f2DC2/1, ...).
- [chia-RS2] y [chib-RPS2i] son las dos partes de la misma red de checksums. La figura 2.c ilustra que [chia-RS2] está embebido en el código de la aplicación de las funciones DC2/1(fiDC2/i, f2DC2/i, ■ ■■) y [chib-RPS2 i] es almacenado en una parte de la base de datos de la aplicación que está asociada a DC2/1. La figura 2.c también se refiere a la posibilidad de que [chib-RPS2i] sea almacenado en formato ofuscado como se describe en la figura 2.d.
- [ch2a-RS2, ch(g+i)-RS2, ch(g+2)-RS2 ..., chm-RS2] y [ch2b-RPS2 i] son calculados como checksums de partes del código de la aplicación de las funciones DC2 /2 (fiDC2/2 , f2 DC2/2, ...) y de al menos partes de uno más parámetros de seguridad [ps2a-RS2 , ps(g+i)-RS2, ps(g+2)-RS2 ..., psm-sR2] embebidos en el código de la aplicación de las funciones DC2 /2 (fiDC2/2, f2 DC2/2, ...).
- [chi2a-RS2, ch(g+i)-RS2, ch(g+2)-RS2..., chm-RS2] son embebidos (hard-coded) en el código de la aplicación de las funciones DC2/2(f1 DC2/2, f2DC2/2, ...).
- [ch2a-RS2] y [ch2b-RPS2i] son las dos partes de la misma red de checksums. La figura 2.c ilustra que [ch2a-RS2] está embebido en el código de la aplicación de las funciones DC2 /2 (fiDC2/2, f2 DC2/2, ...) y [ch2b-RPS2 i] es almacenado en una parte de la base de datos de la aplicación que está asociada a DC2/2. La figura 2.c también se refiere a la posibilidad de que [ch2b-RPS2i] sea almacenado en formato ofuscado como se describe en la figura 2.d.
En términos de reglas de ofuscación de RS2 and RPS21:
- [roia-RS2, ro3-RS2 ro4-RS2 ..., rog-RS2] son embebidas en el código de la aplicación de las funciones DC2/1(f1 DC2/1, f2DC2/1, ...).
- El código de la aplicación de las funciones DC2/ 1(fiDC2/i, f2oo2/ i , ...) junto con los [psia-RS2, ps3-RS2, ps4-rs2..., psg-RS2] y [chia-RS2, ch3-RS2, ch4-RS2..., chg-RS2] embebidos en el código de la aplicación de las funciones DC2/1(fiDC2/i, f2DC2/i, ...) son ofuscados usando [roia-RS2, ro3-RS2, ro4-RS2..., rog-RS2] y [roib-RPS2i].
- [roia-RS2] y [roib-RPS2i] son las dos partes de la misma regla de ofuscación. La figura 2.c illustra que [roia-RS2] está embebida en el código de la aplicación de las funciones DC2/ 1(fiDC2/i, f2DC2/i, ...) y [roib-RPS2i] es almacenada en una parte de la base de datos de la aplicación que está asociada a DC2/ i . La figura 2.c también se refiere a la posibilidad de que [roib-RPS2i] sea almacenada en formato ofuscado como se describe en la figura 2.d.
- [ro2a-RS2, rO(g+i)-RS2 rO(g+2)-RS2..., rOm-RS2] son embebidas en el código de la aplicación de las funciones DC2/2(f1 DC2/2, f2üC2/2, ...).
- El código de la aplicación de las funciones DC2/2(flDC2/2, f2DC2/2, ...) junto con los [ps2a-RS2, ps(g+i)-RS2, ps(g+2)-RS2..., psm-RS2] y [ch2a-RS2, ch(g+i)-RS2, ch(g+2)-RS2. , chm-RS2] embebidos en el código de la aplicación de las funciones DC2 /2 ( f lDC2/2, f2 DC2/2, ...) son ofuscados usando [ro2a-RS2, ro(g+i)-RS2, rote+2)-RS2..., rom-RS2] y [ro2b-RPS2l ].
- [ro2a-RS2] y [ro2b-RPS2i] son las dos partes de la misma regla de ofuscación. La Figura 2.c illustra que [ro2a-RS2] es embebida en el código de la aplicación de las funciones DC2 /2 ( f lDC2/2, f2 DC2/2, ...) y [ro2b-RPS2i] es almacenada en una parte de la base de datos de la aplicación que está asociada a DC2/2. La figura 2.c también se refiere a la posibilidad de que [ro2b-RPS2i] sea almacenada en formato ofuscado como se describe en la figura 2.d.
En términos de parámetros de seguridad de RSi y RPSii:
En términos de redes de checksums de RSi y RPSii:
En términos de reglas de ofuscación de RSi y RPSii:
En esta implementación, en términos de parámetros de seguridad de RSn and RPSni:
- [psia-RSn, ps3-RSn, ps4-RSn ..., psj-RSn] son embebidos (hard-coded) en el código de la aplicación de las funciones C D n/i(ficDn/i, f2cDn/i,...).
- [psia-RSn] y [psib-RPSni] son las dos partes del mismo parámetro de seguridad. [psia-RSn] es embebido en el código de la aplicación de las funciones D C n/i(fiDCn/i, f2Dcn/i, ■■■) y [psib-RPSni] es almacenado en una parte de la base de datos de la aplicación que está asociada a DCn/i.
- [ps2a-RSn, ps(j+i)-RSn ps(j+2)-RSn..., pst-RSn] son embebidos en el código de la aplicación de las funciones DCn/2(fi DCn/2, f2DCn/2, ■■■).
- [ps2a-RSn] y [ps2b-RPSni] son las dos partes del mismo parámetro de seguridad. [ps2a-RSn] es embebido en el código de la aplicación de las funciones DCn/2(fiDCn/2, f2DCn/2, ...) y [ps2b-RPSni] es almacenado en una parte de la base de datos de la aplicación que está asociada a DCn/2.
En términos de las redes de checksums de RSn y RPSni:
- [chia-RSn, chi3-RSn, c lv RSn..., chj-RSn] y [chib-RPSni] son calculados como checksums de partes del código de la aplicación de las funciones D C n/i(fiDcn/i, f2DCn/i, ...) y de al menos partes de uno o más parámetros de seguridad [psia-RSn, ps3-RSn ps4-RSn. , psj-RSn] embebidos en el código de la aplicación de las funciones DCn/i(fi DCn/i, f2DCn/i, ■ ■■).
- [chia-RSn, chi3-RSn, ch4-RSn ..., chj-RSn] son embebidos (hard-coded) en el código de la aplicación de las funciones D C n/i(fiDcn/i, f2DCn/i, ...).
- [chia-RSn] y [chib-RPSni] son las dos partes de la misma red de checksums. [chia-RSn] es embebido en el código de la aplicación de las funciones D C n/i(fiDCn/i, f2Dcn/i, ■■■) y [chib-RPSni] es almacenado en un parte de la base de datos de la aplicación que está asociada a DCn/i.
- [chi2a-RSn, chü+i)-RSn, chü+2)-RSn..., cht-RSn] y [ch2b-RPSni] son calculados como checksums de partes del código de la aplicación de las funciones DCn/2(fiDCn/2, f2DCn/2, ...) y de al menos partes de uno o más parámetros de seguridad [ps2a-RSn, psü+i)-RSn, ps(j+2)-RSn. , pst-RSn] embebidos en el código de la aplicación de las funciones DCn/2(fiDCn/2, f2DCn/2, ...).
- [ch2a-RSn, ch(j+i)-RSn, ch(j+2)-RSn..., cht-RSn] son embebidos (hard-coded) en el código de la aplicación de las funciones DCn/2 ( f iDCn/2, f2 DCn/2, ...).
- [ch2a-RSn] y [ch2b-RPSni] son las dos partes de la misma red de checksums. [ch2a-RSn] es embebido en el código de la aplicación de las funciones DCn/2(fiDCn/2, f2DCn/2, ...) y [ch2b-RPSni] es almacenado en una parte de la base de datos de la aplicación que está asociada a DCn/2.
En términos de reglas de ofuscación de RSn y RPSnl:
- [roia-RSn, ro3-RSn ro4-RSn ..., rOj-RSn] son embebidas en el código de la aplicación de las funciones DCn/1(f1 DCn/1, f¿DCn/1, ...).
- El código de la aplicación de las funciones DCn/1(flDcn/i, f2Dcn/i,...) junto con los [psia-RSn, ps3-RSn, sp4-RSn..., psj-RSn] y [chia-RSn, ch3-RSn, ch4-RSn ..., chj-RSn] embebidos en el código de la aplicación de las funciones D C n/i(fiDcn/i, f2DCn/i, . ) son ofuscados usando[roia-RSn, ro3-RSn, ro4-Rsn. , roj-RSn] y [roib-RPSni].
- [roia-RSn] y [roib-RPSni] son las dos partes de la misma regla de ofuscación. [roia-RSn] es embebida en el código de la aplicación de las funciones D C n/i(fiDcn/i, f2Dcn/i,...) y [roib-RPSni] es almacenada en una parte de la base de datos de la aplicación que está asociada a DCn/i.
- [ro2a-RSn, ro(j+i)-RSn ro(j+2)-RSn..., rot-RSn] son embebidas en el código de la aplicación de las funciones DCn/2(fi DCn/2, f2DCn/2, ■ ■■).
- El código de la aplicación de las funciones DCn/2(fiDCn/2, f2DCn/2, ...) junto con los [ps2a-RSn, ps(j+i)-RSn, ps(j+2)-RSn. , pst-RSn] y [ch2a-RSn, ch(j+i)-RSn, ch(j+2)-RSn. , cht-RSn] embebidos en el código de la aplicación de las funciones DCn/2 ( f iDCn/2, f2 DCn/2, ...) son ofuscados usando [ro2a-RSn, ro(j+i)-RSn, ro(j+2)-RSn..., rot-RSn] y [ro2b-RPSni].
- [ro2a-RSn] y [ro2b-RPSni] son las dos partes de la misma regla de ofuscación. [ro2a-RSn] está embebida en el código de la aplicación de las funciones DCn/2 ( f iDCn/2, f2 DCn/2, ...) y [ro2b-RPSni] está almacenada en una parte de la base de datos de la aplicación que está asociada a DCn/2.
La figura 2.d es relativa a algunas implementaciones asociadas a la ofuscación de al menos partes de parámetros de seguridad, reglas de ofuscación y datos de redes de checksums en una parte de la base de datos de la aplicación que está asociada a un dominio de código dado, en el contexto de generar una aplicación software protegida de dispositivo móvil como la referida en las figuras 2.b y 2.c.
Como se describe en la figura 2.c, en relación a RSx y RPSxi (x = 2, 3, 4 , . , i, ..., n)
- [psia-RSx] y [psib-RPSxi] son las dos partes del mismo parámetro de seguridad y [psib-RPSxi] es almacenado en una parte de la base de datos de la aplicación que está asociada a DCx/i.
- [chia-RSx] y [chib-RPSxi] son las dos partes de la misma red de checksums y [chib-RPSxi] es almacenada en una parte de la base de datos de la aplicación que está asociada a DCx/i.
- [roia-RSx] y [roib-RPSxi] son las dos partes de la misma regla de ofuscación y [roib-RPSxi] es almacenada en una parte de la base de datos de la aplicación que está asociada a DCx/i.
Conforme a algunas implementaciones [psib-RPSxi], [chib-RPSxi] y [roib-RPSxi] son ofuscados por el software de protección de seguridad antes de ser almacenados en la parte correspondiente de la base de datos de la aplicación asociada a DCx/i (la figura 2.d ilustra el almacenamiento en la parte DCx/i - RPSxi de la base de datos de la aplicación).
La figura 2.d muestra un proceso de ofuscar [psib-RPSxi], [chib-RPSxi] y [roib-RPSxi] utilizando un algoritmo de ofuscación (ej. un algoritmo BPS de reservación del formato de datos) y una clave, para proteger esos datos de personalización de seguridad DCx/i. En particular, la figura 2.d ilustra una clave de ofuscación constituida por un checksum x /i de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad que está hard-coded (embebido) en el dominio de código DCi (en relación a DCx/i) como parte de P Irsi, y al menos una parte de un identificador del dispositivo (ej. una parte del MSISDN; para propósito de test por el proveedor de servicios de personalización, un identificador de dispositivo de test - IDDtest - puede ser usado como parte de la clave de ofuscación, como se ilustra en la figura 2.d).
En estas implementaciones DCx/i son primeros dominios de código y DCi es un segundo dominio de código, y DCx/i está vinculado e términos de seguridad a DCi mediante la personalización de [psib-RPSxi], [chib-RPSxi] y [roib-RPSxi] en formato ofuscado en la parte correspondiente de la base de datos de la aplicación.
En la implementación ilustrada en la figura 2.d, cada vinculación DCx/i - DCi depende de un parámetro de seguridad que está hard-coded (embebido) en el código de la aplicación de DCi (en relación a DCx/i). Dicho parámetro de seguridad es requerido por el código de la aplicación de DCx/1 para des ofuscar adecuadamente [psib-RPsxi], [chib-RPSxi] y [roib-RPSxi] para uso, según definido, por el código de la aplicación de DCx/1(f1ocx/i, f2ocx/i,...). Por tanto, un parámetro de seguridad disponible en DCi es requerido para habilitar DCx/i para operación regular.
En un ejemplo particular, el parámetro de seguridad de DCi ha sido ofuscado usando una regla de ofuscación embebida en el código de la aplicación de DCi, por tanto la regla de ofuscación disponible en DCi (en relación al parámetro de seguridad) es requerida para habilitar DCx/i para operación regular (es decir, es requerida para des ofuscar el parámetro de seguridad, que es requerido como parte de la clave para des ofuscar [psib-RPsxi], [chib-RPSxi] y [roib-RPsxi], por lo que la regla de ofuscación es requerida para habilitar DCx/i para operación regular).
En un ejemplo particular, el parámetro de seguridad ha sido usado para calcular una red de checksums que está embebida en el código de la aplicación de DCi, por lo que una adecuada verificación de la red de checksums por el código de aplicación de DCi es requerida, para habilitar DCx/i para operación regular (ej. si la red de checksums no es adecuadamente verificada, el código de aplicación de DCi detendrá su ejecución, por lo que el parámetro de seguridad de CDi no podrá ser obtenido, y DCx/i no será habilitado para operación regular).
Ventajosamente, la aplicación generada incluye varios dominios de código, relativos a los uno o más proveedores de servicio, donde uno o más primeros dominios de código (ej. DCx/i) son vinculados en términos de seguridad a uno o más segundos dominios de código (ej. DCi) a través de la personalización de seguridad ([psib-RPSxi], [chib-RPsxi] and [roib-RPsxi] almacenados en la base de datos de la aplicación en formato ofuscado), dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código (el parámetro de seguridad y/o regla de ofuscación y/o datos checksums en DCi referidos anteriormente) y que son requeridos para habilitar los uno o más primeros dominios de código para operación regular (ej. que es/son requeridos para des ofuscar ([psib-RPsxi], [chib-RPsxi] y [roib-RPsxi] para uso por DCx/i).
Conforme a algunas implementaciones cada uno de [psib-RPsxi], [chib-RPsxi] y [roib-RPsxi] es ofuscado usando una clave de ofuscación diferente. En un ejemplo particular:
- La clave usada para ofuscar [psib-RPsxi] está constituida por un checksum de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad (ej. [psix-Rsi]) que está hard-coded (embebido) en el código de la aplicación de DCi (en relación a DCx/i) como parte de P Irsi, y una parte de un identificador de dispositivo (ej. el MsisDN o un cálculo basado en el MsisDN, la dirección MAC, etc.).
- La clave usada para ofuscar [chib-RPsxi] está constituida por un checksum de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad (ej. [p%-Rsi]) que está hard-coded (embebido) en el código de la aplicación de DCi (en relación a DCx/i) como parte de P Irsi, y una parte de un identificador de dispositivo.
- La clave usada para ofuscar [roib-RPsxi] está constituida por un checksum de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad (ej. [pskx-Rsi]) que está hard-coded (embebido) en el código de la aplicación de DCi (en relación a DCx/i) como parte de P Irsi, y una parte de un identificador de dispositivo.
Para propósitos de test por el proveedor de servicios de personalización, un identificador de dispositivo de test - IDDtest - puede ser usado como parte de la correspondiente clave de ofuscación.
En estas implementaciones, DCx/i (primeros dominios de código) son también vinculados en términos de seguridad a DCi (segundo dominio de código) mediante la personalización de [psib-RPsxi], [chib-RPsxi] and [roib-RPsxi] en formato ofuscado en la parte correspondiente de la base de datos de la aplicación.
Cada vinculación DCx/i - DCi depende, respectivamente en términos de [psib-RPsxi] / [chib-RPsxi] / [roib-RPsxi], del parámetro de seguridad [psix-Rsi] / [pj -R s i ] / [pskx-Rsi]. Dicho parámetro de seguridad [psix-Rsi] / [pV rsi] / [pskx-Rsi] es requerido por el código de la aplicación de DCx/i para respectivamente y adecuadamente des ofuscar [psib-RPsxi] / [chib-RPsxi] / [roib-RPsxi] para uso, según definido, por el código de la aplicación de DCx/i(fi DCx/i, f2DCx/i, ■■■). Por tanto, parámetros de seguridad disponibles en DCi son requeridos para habilitar DCx/i para operación regular.
En un ejemplo particular, los parámetros de seguridad [pSix-Rsi] / [psjx-sRi] / [pSkx-Rsi] de DC1 han sido ofuscados usando una o más reglas de ofuscación embebidas en el código de la aplicación de DC1, por lo que reglas de ofuscación disponibles en DC1 (en relación a los parámetros de seguridad) son requeridas para habilitar DCx/1 para operación regular (es decir son requeridas para des ofuscar los parámetros de seguridad, que son requeridos para calcular las claves de des ofuscación, por lo que las reglas de ofuscación son requeridas para habilitar DCx/1 para operación regular).
En un ejemplo particular, los parámetros de seguridad [psix-RS1] / [p%-RS1] / [pskx-RS1] han sido usados para calcular una o más redes de checksums que están embebidas en el código de la aplicación de DC1, por lo que una verificación adecuada de las redes de checksums por el código de la aplicación de DC1 es requerida para habilitar DCx/1 para operación regular (ej. si las redes de checksums no son adecuadamente verificadas, el código de la aplicación de DC1 detendrá su ejecución, por lo que los parámetros de seguridad de DC1 no serán obtenidos, y DCx/1 no será habilitado para operación regular).
Ventajosamente, la aplicación generada incluye varios dominios de código, relativos a los uno o más proveedores de servicios, donde uno o más primeros dominios de código (ej. DCx/1) son vinculados en términos de seguridad a uno o más segundos dominios de código (ej. DC1) a través de la personalización de seguridad ([ps-ib-RPSx1 ], [ch1b-RPSx1] y [ro1b-RPSx1] almacenados en la base de datos de la aplicación en formato ofuscado), dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código (el parámetro de seguridad y/o regla de ofuscación y/o datos de checksums en DC1 referidos anteriormente) y que son requeridos para habilitar los uno o más primeros dominios de código para operación regular (ej. que es/son requeridos para des ofuscar ([ps1b-RPSx1], [ch1b-RPSx1] y [ro1b-RPSx1] para uso por DCx/1).
Como también se describe en la figura 2.c, en relación a RSx y RPSx1 (x = 2, 3, 4,..., i, ..., n)
- [ps2a-RSx] y [ps2b-RPSx1] son las dos partes del mismo parámetro de seguridad y [ps2b-RPSx1] es almacenado en una parte de la base de datos de la aplicación que está asociada a DCx/2.
- [ch2a-RSx] y [ch2b-RPSx1] son las dos partes de la misma red de checksums y [ch2b-RPSx1] es almacenado en una parte de la base de datos de la aplicación que está asociada a DCx/2.
- [ro2a-RSx] y [ro2b-RPSx1] son las dos partes de la misma regla de ofuscación y [ro2b-RPSx1] es almacenada en una parte de la base de datos de la aplicación que está asociada a DCx/2.
Conforme a algunas implementaciones [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] son ofuscados por el software de protección de seguridad antes de ser almacenados en la parte correspondiente de la base de datos de la aplicación asociada a DCx/2 (la figura 2.d ilustra el almacenamiento en la parte DCx/2 - RPSx1 de la base de datos de la aplicación).
La figura 2.d muestra un proceso de ofuscar [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] usando un algoritmo de ofuscación y una clave, para proteger esos datos de personalización de seguridad DCx/2. En particular, la figura 2.d ilustra una clave de ofuscación constituida por un checksum x/2 de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad que está al menos parcialmente hard-coded (embebido) en el dominio de código DCx/1 (en relación a DCx/2) como parte de Pxrsx, y al menos una parte de un identificador de dispositivo (ej. al menos una parte del MSISDN; para propósitos de test por el proveedor de servicios de personalización, un identificador de dispositivo de test - IDDtest - puede ser usado como parte de la clave de ofuscación, como se ilustra en la figura 2.d).
Conforme a algunas implementaciones el parámetro de seguridad está al menos parcialmente hard-coded en el domino de código DCx/1 y parcialmente almacenado en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a DCx/1. En un ejemplo particular, la parte hard-coded en el domino de código DCx/1 (en relación a DCx/2) es al menos una parte de [ps1a-RSx] y la parte almacenada en la base de datos de la aplicación es al menos una parte de [ps1b-RPSx1] (que a este respecto está también asociada a DCx/2). Ventajosamente, en este ejemplo, des ofuscar [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] requiere una personalización previa de [ps1b-RPSx1] en la parte correspondiente de la base de datos de la aplicación (es decir en DCx/1 -RPSx/1) y su des ofuscación para uso en el cálculo de la clave de ofuscación que protege datos de personalización de seguridad de DCx/2.
En estas implementaciones DCx/1 son primeros dominios de código y DCx/2 son otros primeros dominios de código y DCx/2 son respectivamente vinculados en términos de seguridad a DCx/1 a través de la personalización de [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] en formato ofuscado en la parte correspondiente de la base de datos de la aplicación (en el ejemplo anterior cada vinculación DCx/2 - DCx/1 depende de una parte de un parámetro de seguridad que está hard-coded (embebido) en el código de la aplicación de DCx/1 y de una parte de ese parámetro de seguridad que está almacenada en la base de datos de la aplicación).
Por tanto, dicha al menos parte del parámetro de seguridad [ps1a-RSx] / [psn>RPSx1] es requerida por el código de la aplicación de DCx/2 para des ofuscar adecuadamente [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] para uso, según definido, por el código de la aplicación de DCx/2(f1ocx/2, f2ücx/2, ...). Por tanto, en esas implementaciones al menos una parte de un parámetro de seguridad disponible en una parte de la base de datos de la aplicación que está asociada a DCx/1 (es decir en DCx/1 - RPSx1) es requerida para habilitar DCx/2 para operación regular.
En un ejemplo particular, la parte [ps1a-RSx] del parámetro de seguridad ha sido ofuscada usando una regla de ofuscación que está parcialmente hard-coded en el domino de código CDx/1 [ej. al menos parte de ro1a-sRx] y parcialmente almacenada en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a DCx/1 [ej. al menos parte de ro1b-RPSx1]. Por tanto en estas implementaciones al menos una parte de una regla de ofuscación disponible en una parte de la base de datos de la aplicación que está asociada a DCx/1 (es decir en DCx/1 - RPSx1) es requerida para habilitar DCx/2 para operación regular (es decir es requerida para des ofuscar una parte del parámetro de seguridad, que es requerido como parte de la clave para des ofuscar [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1], por lo que la parte de la regla de ofuscación disponible en la parte correspondiente de la base de datos de la aplicación es requerida para habilitar DCx/2 para operación regular).
En un ejemplo particular, la parte [ps1a-RSx] del parámetro de seguridad ha sido usada para calcular una red de checksums que está parcialmente hard-coded en el domino de código DCx/1 [ej. ch1a-RSx] y parcialmente almacenada en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a DCx/1 [ej. ch1b-RPSx1]. En este ejemplo, una verificación adecuada de la parte de la red de checksums disponible en una parte de la base de datos de la aplicación que está asociada a DCx/1 (es decir en DCx/1 - RPSx1) es requerida para habilitar DCx/2 para operación regular (ej. si la red de checksums no es verificada adecuadamente, el código de la aplicación de DCx/1 detendrá su ejecución, por lo que el parámetro de seguridad de DCx/1 no será obtenido, y DCx/2 no será habilitado para operación regular).
Ventajosamente, otro uno o más primeros dominios de código (ej. DCx/2) es vinculado en términos de seguridad a uno o más primeros dominios de código (ej. DCx/1) a través de la personalización de seguridad ([ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] almacenados en la base de datos de la aplicación en formato ofuscado), dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código (el parámetro de seguridad y/o regla de ofuscación y/o datos de checksums en DCx/1 referidos anteriormente) y que son requeridos para habilitar el otro uno o más primeros dominios de código para operación regular (ej. que es/son requeridos para des ofuscar [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] para uso por DCx/2).
Conforme a algunas implementaciones cada uno de [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-rpsx1] son ofuscados usando una clave de ofuscación diferente. En un ejemplo particular:
- La clave usada para ofuscar [ps2b-RPSx1] está constituida por un checksum de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad (ej. incluyendo una parte [ps1a1-RSx] que está hard-coded (embebida) en el código de la aplicación de DCx/1 y una parte [ps1b1-RPSx1] que es almacenada en formato ofuscado en la base de datos de la aplicación) y una parte de un identificador del dispositivo (ej. el MSISDN o un cálculo basado en el MSISd N, la dirección MAC, etc.).
- La clave usada para ofuscar [ch2b-RPSx1] está constituida por un checksum de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad (ej. incluyendo una parte [ps1a2-RSx] que está hard-coded (embebida) en el código de la aplicación de DCx/1 y una parte [ps1b2-RPSx1] que es almacenada en formato ofuscado en la base de datos de la aplicación) y una parte de un identificador de dispositivo.
- La clave usada para ofuscar [ro2b-RPSx1] está constituida por un checksum de la aplicación software protegida de dispositivo móvil, un parámetro de seguridad (ej. incluyendo una parte [ps1a3-RSx] que está hard-coded (embebida) en el código de la aplicación de DCx/1 y una parte [sp1b3-SPRx1] que es almacenada en formato ofuscado en la base de datos de la aplicación) y una parte de un identificador de dispositivo.
Para propósitos de test por el proveedor de servicios de personalización, un identificador de dispositivo de test - DIDtest - puede ser usado como parte de la correspondiente clave de ofuscación.
Ventajosamente, en este ejemplo, des ofuscar [ps2b-RPsxi], [ch2b-RPSxi] y [ro2b-RPSxi] requiere personalización previa de [ps1M-RPsx1], [ps1b2-RPSx1] y [ps1b3-RPSx1] (los cuales ej. pueden ser diferentes partes de [ps1b-RPSx1]) en la parte correspondiente de la base de datos de la aplicación (es decir en DCx/1 - RPSx/1) y su des ofuscación para uso en el cálculo de la respectiva clave de ofuscación que protege los datos relativos de personalización de seguridad de DCx/2.
En estas implementaciones DCx/1 son primeros dominios de código y DCx/2 son otros primeros dominios de código y DCx/2 son respectivamente vinculados en términos de seguridad a DCx/1 a través de la personalización de [ps2b-RPsx1], [ch2b-RPSx1] y [ro2b-RPSx1] en formato ofuscado en la parte correspondiente de la base de datos de la aplicación. Cada vinculación DCx/2 - DCx/1 depende, en términos de [ps2b-RPSx1] / [ch2brpsx1] / [ro2b-RPSx1], respectivamente del parámetro de seguridad [ps1a1-R&J & [ps1b1-Rpsx1 / [ps1a2-Rsx] & [ps1b2-RPSx1] / [ps1a3-RSx] & [ps1b3-RPSx1].
Por tanto, dicho parámetro de seguridad [p s ^ -RSx] & [ps1b1-RPSx1] / [ps1a2-RSx] & [ps1b2-RPsx1] / [ps1a3-RSx] & [p s ^ -rpsx1] es requerido por el código de la aplicación de DCx/2 para respectivamente y adecuadamente des ofuscar [ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] para uso, según definido, por el código de la aplicación de DCx/2 (f1 DCx/2, f2 DCx/2, ...). Por tanto, en esas implementaciones al menos una parte de parámetros de seguridad disponibles en una parte de la base de datos de la aplicación que está asociada a DCx/1 (es decir en DCx/1 - RpSx1) es requerida para habilitar DCx/2 para operación regular.
En un ejemplo particular, la parte [ps1a1-RSx] / [ps1a2-RSx] / [ps1a3-RSx] del respectivo parámetro de seguridad ha sido ofuscada usando una o más reglas de ofuscación que están parcialmente hard-coded en el dominio de código CDx/1 y parcialmente almacenadas en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a CDx/1. Por tanto, en estas implementaciones al menos una parte de una o más reglas de ofuscación disponible en una parte de la base de datos de la aplicación que está asociada a DCx/1 (es decir en DCx/1 - RPSx1) es requerida para habilitar DCx/2 para operación regular (es decir es/son requeridas para des ofuscar una parte de los parámetros de seguridad, que son requeridos para calcular las claves de des ofuscación, tal que la(s) parte(s) de la(s) regla(s) de ofuscación disponibles en la parte correspondiente de la base de datos de la aplicación en relación a DCx/1 es/son requeridas para habilitar DCx/2 para operación regular.
En un ejemplo particular, las partes [ps1a1-Rsx] / [ps1a2-RSx] / [ps1a3-RSx] de los parámetros de seguridad han sido usadas para calcular una o más redes de checksums que son parcialmente hard-coded en el dominio de código DCx/1 y parcialmente almacenados en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a DCx/1. En este ejemplo, una verificación adecuada de la parte de las redes de checksums disponible en una parte de la base de datos de la aplicación que está asociad a DCx/1 (es decir en DCx/1 -RPSx1) es requerida para habilitar DCx/2 para operación regular (ej. si las redes de checksums no son adecuadamente verificadas, el código de la aplicación de DCx/1 detendrá su ejecución, por lo que el parámetro de seguridad de DCx/1 no será obtenido, y DCx/2 no será habilitado para operación regular.
Ventajosamente, otro uno o más primeros dominios de código (ej. DCx/2) es vinculado en términos de seguridad a uno o más primeros dominios de código (ej. DCx/1) a través de la personalización de seguridad ([ps2b-RPSx1], [ch2b-RPSx1] y [ro2b-RPSx1] almacenados en la base de datos de la aplicación en formato ofuscado), dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código (el parámetro de seguridad y/o regla de ofuscación y/o datos de checksums en DCx/1 referidos anteriormente) y que son requeridos para habilitar el otro uno o más primeros dominios de código para operación regular (ej. que es/son requeridos para des ofuscar [ps2b-RPsx1], [ch2b-RPSx1] y [ro2b-spRx1] para uso por DCx/2).
La figura 2.b ha sido descrita anteriormente en relación a la generación de una aplicación software protegida de dispositivo móvil personalizada en seguridad, asociada al registro de personalización de seguridad RPs-I. La aplicación incluye varios dominios de código, cada uno agrupando una o más funciones de la aplicación software de dispositivo móvil que están asociadas al proveedor de servicios.
Como ya se ha detallado anteriormente en relación a la figura 2.b, conforme a algunas implementaciones la aplicación software de dispositivo móvil puede lograr el mismo nivel de funcionalidad usando [(f1 DCk/1, f2 DCk/1 ■■■) en DCk/1 y (f1 DCk/2, f2DCk/2, ■■■) en DCk/2] que usando [(f1 dci/1, f2ool/1, ...) en DCl/1 y (f1 DCl/2, f2Dci/2, ...) en DCl/2], k y l en el rango de 1 a n.
En la implementación ilustrada en la figura 2.b, un proceso de ofuscación es aplicado por el software de protección de seguridad al código de la aplicación software de dispositivo móvil, y a parámetros de seguridad del registro de personalización de seguridad, y a checksums de las redes de checksums del registro de personalización de seguridad.
Conforme a algunas implementaciones, una vez que la aplicación software protegida de dispositivo móvil ha sido generada, el proveedor de servicios de personalización verifica que la protección de seguridad ha sido aplicada adecuadamente, usando un parámetro de seguridad (psDCs-asignación] que está disponible en la parte correspondiente de la base de datos de la aplicación (como se ilustra en la figura 2.b) y que permite asignar para ejecución por un dispositivo móvil dado un conjunto dado de dominios de código, u otro diferente, de la siguiente forma:
- Si el parámetro de seguridad se establece en un valor dado asociado a DC2/1 y CD2/2 entonces la aplicación software protegida de dispositivo móvil puede usar las funciones de DC1, DC2/1 y CD2/2 durante su ejecución.
- Si el parámetro de seguridad se establece en un valor dado asociado a DC3/1 y DC3/2 entonces la aplicación software protegida de dispositivo móvil puede usar las funciones de DC1, DC3/1 y DC3/2 durante su ejecución.
- Si el parámetro de seguridad se establece en un valor dado asociado a DC4/1 y DC4/2 entonces la aplicación software protegida de dispositivo móvil puede usar las funciones de DC1, DC4/1 y DC4/2 durante su ejecución.
- Si el parámetro de seguridad se establece en un valor dado asociado a DCi/1 y DCi/2 entonces la aplicación software protegida de dispositivo móvil puede usar las funciones de DC1, DCi/1 y DCi/2 durante su ejecución.
- Si el parámetro de seguridad se establece en un valor dado asociado a DCn/1 y DCn/2 entonces la aplicación software protegida de dispositivo móvil puede usar las funciones de DC1, DCn/1 y DCn/2 durante su ejecución.
Conforme a algunas implementaciones el valor del parámetro de seguridad spCDs-asignación es almacenado en formato ofuscado en la parte correspondiente de la base de datos de la aplicación. En un ejemplo particular el método para ofuscar psDCs-asignación utiliza un parámetro de seguridad que está embebido en funciones de DC1. En otro ejemplo particular el método para ofuscar psDCs-asignación utiliza un parámetro de seguridad que está embebido en una función de DC1 y al menos una parte de un identificador de dispositivo móvil. Durante su ciclo de vida una vez instalada en un dispositivo móvil, la aplicación software protegida de dispositivo móvil será capaz de obtener el referido parámetro de seguridad (/y el al menos parte del identificador de dispositivo móvil), para des ofuscar psDCs-asignación e identificar los dominios de código que pueden ser usados durante la ejecución de la aplicación en dicho dispositivo móvil.
Conforme a algunas implementaciones, una vez que la aplicación software protegida de dispositivo móvil ha sido generada, puede ser testada para verificar que la protección de seguridad asociada a RPS-I ha sido aplicada adecuadamente. El test puede ser realizado usando ej. un dispositivo móvil de test o ej. un emulador de dispositivo móvil (el identificador de dispositivo móvil del dispositivo móvil de test o emulador es denominado como IDDtest en el contexto de las figuras 2.b, 2.c y 2.d).
Para realizar los test:
- El parámetro de seguridad psDCs-asignación puede ser primero establecido al valor asociado a DC2/1 y DC2/2, tal que la aplicación software protegida de dispositivo móvil pueda usar las funciones de DC1, DC2/1 y DC2/2 durante su ejecución. El proceso de test debe verificar que cuando P2rps21 ha sido aplicada (es decir datos de RPS21 están almacenados en formato ofuscado en una parte de la base de datos de la aplicación que está asociada a DC2/1 y DC2/2), DC2/1 y CD2/2 están habilitados para operación regular;
- Una vez finalizados los test asociados a DC2/1 y CD2/2, el parámetro de seguridad psDCs-asignación puede ser establecido al valor asociado a DC3/1 y CD3/2 para testar que cuando P3rps3i ha sido aplicada, DC3/1 y DC3/2 están habilitados para operación regular;
- Una vez finalizados los test asociados a DC(n-1)/1 y DC(n-1)/2, el parámetro de seguridad psDCs-asignación puede ser establecido al valor asociado a DCn/1 y DCn/2 para testar que cuando PnRPSni ha sido aplicada, DCn/1 y DCn/2 están habilitados para operación regular.
Cuando el parámetro de seguridad psDCs-asignación es establecido al valor asociado a DCx/1 y DCx/2, conforme a algunas implementaciones la protección de seguridad personalizada ([psn>RPSx1, ch1b-RPsx1, ron>RPSx1] almacenados en formato ofuscado en la parte correspondiente de la base de datos de la aplicación) asociada a DCx/1 y a IDDtest, es usada y testada de la siguiente forma:
- Una o más partes del parámetro de seguridad [ps1a-RSx / ps1b-RPSx1 son usadas para validar que una solicitud para pre registrar un primer servicio, asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo apropiado y ha sido lanzada desde el código de dominio adecuado (CDx/1) con la personalización de seguridad adecuada. Durante dicho proceso las una o más partes de [ps1a-RSx / psn>RPSx1] son des ofuscadas, y un cálculo basado en las unas o más partes des ofuscadas de [ps1a-RSx / ps1b-RPSx1] es enviado al proveedor de servicios 1 para verificación. En el contexto del proceso de test, el dispositivo adecuado es el de identificador de dispositivo IDDtest y el proceso de verificación es realizado por un sistema de test del proveedor de servicios de personalización.
- Otras una o más partes del parámetro de seguridad [ps1a-RSx / ps1b-RPSx1] son usadas para proteger datos en ciertas partes de la base de datos de la aplicación software protegida de dispositivo móvil (cuando psDCs-asignación es establecido al valor asociado a DCx/1 y DCx/2). En una implementación particular, dichas otras una o más partes del parámetro de seguridad son usadas para proteger al menos parte de la parte de la base de datos de la aplicación que no está asociada a personalización de seguridad / asignación de dominios de código. Cuando la aplicación software protegida de dispositivo móvil recibe datos para almacenamiento en la al menos parte de la parte de la base de datos que no está asociada a personalización de seguridad / asignación de dominios de código, esos son cifrados usando las referidas otras una o más partes del parámetro de seguridad [ps1a-RSx / ps1b-RPSx1], antes de ser almacenados en la correspondiente al menos parte de la parte de la base de datos de la aplicación.
Cuando la aplicación software protegida de dispositivo móvil requiere el uso de datos almacenados en dicha al menos parte de la parte de la base de datos, las otras una o más partes de del parámetro de seguridad [ps1a-RSx / psn>RPSx1] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar los datos en la base de datos, para uso. En el contexto del proceso de test el dispositivo usado es el de identificador de dispositivo IDDtest.
- Otras una o más partes del parámetro de seguridad [ps1a-Rsx / psn>RPSx1] son el parámetro de seguridad que es parte de la clave de ofuscación usada para ofuscar [ps2b-RPsx1], [ch2b-RPsx1 y [rc>2b-RPsx1] (cuando psDCs-asignación es establecido al valor asociado a DCx/1 y DCx/2).
- La red de checksums [ch1a-RSx / ch1b-RPSx1] es usada para verificar la integridad de partes del código de la aplicación de las funciones DCx/1 (f1 DCx/1, f2 DCx/1, ■■■) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/1 (f1 DCx/1, í2 dcx/1, ...).
Cuando a aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [ch1a-RSx / ch1b-RPsx1] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. En el contexto del proceso de test el dispositivo utilizado es el de identificador de dispositivo IDDtest.
o En una implementación alternativa:
• una o más partes de la red de checksums [ch1a-RSx / ch1b-RPsx1] son usadas para verificar la integridad de partes del código de la aplicación de las funciones DCx/1 (f1 DCx/1, f2 Dcx/1, ■■■) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/1 (f1 DCx/1, f2 DCx/1, ...) cuando un parámetro en psDCs-asignación es establecido a un primer valor;
• otras una o más partes de la red de checksums [ch1a-RSx / ch1b-RPsx1] son usadas para verificar la integridad de otras partes del código de la aplicación de las funciones DCx/1 (f1 DCx/1, f2 DCx/1, ...) y de al menos partes de otros uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/1 (f1 DCx/1, f2 DCx/1, ...) cuando un parámetro en psDCs-asignación es establecido a un segundo valor;
• otras una o más partes de la red de checksums [ch1a-RSx / ch1b-RPsx1] son usadas para verificar la integridad de otras partes del código de la aplicación de las funciones DCx/1 (f1 DCx/1, f2 DCx/1, ■■■) y de al menos partes de otros uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/1(f1ocx/i, f2ocx/i, ■■■) cuando un parámetro en psocs-asignación es establecido a un enésimo valor;
Ventajosamente, dependiendo del valor establecido en psocs-asignación, una parte(s) diferente de [chiarsx / chib-RPSxi] puede ser usada en la verificación de integridad. El proceso de test puede testar todos los posibles valores, usando el identificador de dispositivo IDDtest como dispositivo utilizado.
- La regla de ofuscación [roia-RSx / roib-RPsxi] es usada para ofuscar parte del código de la aplicación de las funciones DCx/i(fiocx/i, f2ocx/i, ...) junto con parte [psia-RSx, ps3-RSx, ps4-Rsx..., psg-RSx] y parte de [chia-RSx, ch3-RSx ch4-RSx ..., chg-RSx] embebidos en el código de la aplicación de las funciones DCx/i(fiocx/i, f2ocx/i ■■■).
Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha parte referida del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas, el correspondiente proceso de des ofuscación es aplicado usando [roia-RSx / roib-RPsxi]. En el contexto del proceso de test el dispositivo utilizado es el de identificador de dispositivo IDDtest.
o En una implementación alternativa al menos una función dada en CDx/i (fiocx/i) es codificada g-veces en DCx/i, las instrucciones de cada réplica de la función siendo equivalentes en términos de funcionalidad. En esta implementación alternativa, parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la primera réplica es ofuscada usando una o más partes de la regla de ofuscación [roia-RSx / roib-RPsxi], ...., parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la G-réplica es ofuscada usando otras una o más partes de la regla de ofuscación [roia-RSx / roib-RPsxi]. También:
• La una o más partes de la regla de ofuscación [roia-RSx / roib-RPsxi] son usadas para des ofuscar la parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la primera réplica de la función cuando un parámetro en psocs-asignación es establecido a un primer valor;
• Las otras una o más partes de la regla de ofuscación [roia-RSx / roib-RPsxi] son usadas para des ofuscar la parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la G-réplica de la función cuando un parámetro en psocs-asignación es establecido a un G valor;
Ventajosamente, dependiendo del valor establecido en psocs-asignación, diferentes una o más partes de [roia-RSx / roib-RPsxi] son usadas en la des ofuscación de la correspondiente parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la correspondiente réplica de la al menos una función fiocx/i dada. El proceso de test puede testear todos los posibles valores, usando el identificador de dispositivo Iootest como dispositivo usado.
También, cuando el parámetro de seguridad psocs-asignación se establece al valor asociado a o cx /i y ocx/2, conforme a algunas implementaciones la personalización de seguridad personalizada ([ps2b-RPsxi, ch2b-RPsxi, ro2b-RPsxi] almacenados en formato ofuscado en la correspondiente parte de la base de datos de la aplicación) asociada a ocx/2 y a Iootest, es usada a testada de la siguiente forma:
- Una o más partes del parámetro de seguridad [ps2a-Rsx / ps2b-RPsxi] son usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde ocx/2 a partir de un pre registro previo con éxito del primer servicio), asociada al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo apropiado y ha sido lanzada desde el dominio de código adecuado (ocx/2) con la personalización de seguridad adecuada. ourante dicho proceso las una o más partes de [ps2a-Rsx / ps2b-RPsxi] son des ofuscadas, y un cálculo basado en las des ofuscadas una o más partes de [ps2a-Rsx / ps2b-RPsxi] es enviado al proveedor de servicios i para verificación. En el contexto del proceso de test, el dispositivo apropiado es el de identificador de dispositivo Iootest y el proceso de verificación es realizado por un sistema de test del proveedor de servicios de personalización.
conforme a algunas implementaciones un PIN (Personal Identification Number) es seleccionado por el usuario durante el proceso de registrar un primer servicio del proveedor de servicios i en la aplicación software protegida de dispositivo móvil, y datos almacenados en la base de datos de la aplicación software protegida de dispositivo móvil durante la fase de pre registro son usados para autenticar el registro del PIN seleccionado en el sistema del proveedor de servicios i.
3i
- Otras una o más partes del parámetro de seguridad [ps2a-RSx / ps2b-RPSxi] son usadas para proteger ciertos datos sensibles no estructurados antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil (ej. para proteger claves / datos sensibles necesarios para que la aplicación software protegida de dispositivo móvil calcule credenciales dinámicas asociadas a servicios provistos por el proveedor de servicios 1; ej. protección de claves de sesión), cuando psDCs-asignación es establecido al valor asociado a DCx/1 y DCx/2. Conforme a algunas implementaciones, los datos sensibles no estructurados son cifrados por el proveedor de servicios 1, o por un tercero en nombre del proveedor de servicios 1, utilizando las otras una o más partes de [ps2a-RSx / ps2b-RPSx1] y enviados a la aplicación software protegida de dispositivo móvil para almacenamiento en la base de datos de la aplicación.
Cuando la aplicación software protegida de dispositivo móvil requiere el uso de al menos parte de los datos sensibles no estructurados, las otras una o más partes del parámetro de seguridad [ps2a-RSx / ps2b-RPSx1] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar la al menos parte de los datos sensibles no estructurados almacenados, para uso. En el contexto del proceso de test el dispositivo usado es el de identificador de dispositivo IDDtest.
- Otras una o más partes del parámetro de seguridad [ps2a-RSx / ps2b-RPSx1] son usadas para ofuscar ciertos datos sensibles, en el contexto de la ejecución de algunas instrucciones de código de DCx/2, para evitar que sean expuestos en claro en una o más memorias de trabajo del dispositivo móvil, cuando psDCs-asignación es establecido al valor asociado a DCx/1 y DCx/2.
Conforme a algunas implementaciones ciertos datos sensibles (ej. una o más claves) son ofuscadas antes de ser temporalmente almacenadas en una o más memorias de trabajo del dispositivo móvil en el contexto de la ejecución de ciertas instrucciones de código relativas a DCx/2 por una o más dispositivos de procesamiento en el dispositivo móvil, tal que dichos datos sensibles no sean expuestos en claro en las memorias de trabajo.
En un ejemplo particular la regla de ofuscación usa las otras una o más partes del parámetro de seguridad [ps2a-RSx / ps2b-RPSx1] y es relativa a mezclar los datos sensibles con conjuntos de datos no-útiles, para uso temporal en las unas o más memorias de trabajo.
Cuando, durante la ejecución de ciertas instrucciones de código de DCx/2, los uno o más dispositivos de procesamiento requieren usar los datos sensibles ofuscados previamente almacenados en las una o más memorias de trabajo, utilizan las otras una o más partes de [ps2a-RSx / ps2b-RPSx1] y la regla de ofuscación para obtener los datos adecuados para el relativo proceso de cálculo.
La lógica anterior puede ser repetida conforme a la programación de las funciones de DCx/2 tal que las otras una o más partes de [ps2a-RSx / ps2b-RPSx1] servirán para evitar que ciertos datos sensibles sean expuestos en claro en las una o más memorias de trabajo del dispositivo móvil durante los sucesivos cálculos por los uno o más dispositivos de procesamiento que usan esos datos sensibles.
En el contexto del proceso de test el dispositivo utilizado es el de identificador de dispositivo IDDtest.
- La red de checksums [ch2a-RSx / ch2b-RPSx1] es usada para verificar la integridad de partes del código de la aplicación de las funciones DCx/2 (f1 DCx/2, f2 DCx/2, ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/2 (f1 DCx/2, f2 DCx/2, ...).
Cuando la aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [ch2a-RSx / ch2b-RPSx1] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. En el contexto del proceso de test el dispositivo utilizado es el de identificador de dispositivo IDDtest.
o En una implementación alternativa:
• una o más partes de la red de checksums [ch2a-sRx / ch2b-spRx1] son usadas para verificar la integridad de partes del código de la aplicación de las funciones DCx/2 (f1 DCx/2, f2 DCx/2, ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/2(f1DCx/2, f2DCx/2, ...) cuando un parámetro en psDCs-asignación es establecido a un primer valor;
• otras una o más partes de la red de checksums [ch2a-sRx / ch2b-spRxi] son usadas para verificar la integridad de otras partes del código de la aplicación de las funciones DCx/2(f1ocx/2, f2ücx/2, ...) y de al menos partes de otros uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/2(f1ocx/2, f2ücx/2, ...) cuando un parámetro en psocs-asignación es establecido a un segundo valor;
• otras una o más partes de la red de checksums [ch2a-sRx / ch2b-spRxi] son usadas para verificar la integridad de otras partes del código de la aplicación de las funciones DCx/2(f1ocx/2, f2ocx/2, ...) y de al menos partes de otros uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DCx/2(f1ocx/2, f2ocx/2, ...) cuando un parámetro en psocs-asignación es establecido a un enésimo valor;
Ventajosamente, dependiendo del valor establecido en psocs-asignación, una parte diferente de [ch2a-RSx / ch2b-RPSx1] puede ser usada in la verificación de integridad. El proceso de test puede testear todos los valores posibles, usando el identificador de dispositivo IDDtest como dispositivo utilizado.
- La regla de ofuscación [ro2a-RSx / ro2b-RPSx1] es usada para ofuscar parte del código de la aplicación de las funciones DCx/2(f1ocx/2, f2ocx/2, ...) junto con parte de los [ps2a-RSx, ps(g+1)-RSx, ps(g+2)-RSx ..., psm-RSx] y parte de los [chi2a-RSx, ch(g+1)-RSx ch(g+2)-RSx ..., chm-RSx] embebidos en el código de la aplicaciones de las funciones o cx /2 (f1 DCx/2, f2üCx/2, ■ ■■).
Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha referida parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas, el correspondiente proceso de des ofuscación es aplicado usando [ro2 a-RSx / ro2 b-RPSx1]. En el contexto del proceso de test el dispositivo utilizado es el de identificador de dispositivo IDDtest.
o En una implementación alternativa al menos una función dada en DCx/2 (fiocx/ 2 ) es codificada h-veces en DCx/2, siendo las instrucciones de cada réplica de la función equivalentes en términos de funcionalidad. En esta implementación alternativa, parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la primera replica son ofuscados usando una o más partes de la regla de ofuscación [ro2 a-RSx / ro2 b-RPSx1], ...., parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la H-replica son ofuscados usando otras una o más partes de la regla de ofuscación [ro2 a-RSx / ro2 b-RPSx1]. También:
• Las una o más partes de la regla de ofuscación [ro2 a-RSx / ro2 b-RPSx1] son usadas para des ofuscar la parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la primera replica de la función cuando un parámetro en psDCs-asignación es establecido a un primer valor;
• Las otras una o más partes de la regla de ofuscación [rc>2 a-RSx / ro2 b-RPSx1] son usadas para des ofuscar la parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la H-replica de la función cuando un parámetro en psDCs-asignación es establecido a un H-valor;
Ventajosamente, dependiendo del valor establecido en psDCs-asignación, diferentes una o más partes de [ro2 a-RSx / ro2 b-RPSx1] son usadas en la des ofuscación de la correspondiente parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la correspondiente réplica de la al menos una función fiDCx/2 dada. El proceso de test puede testear todos los posibles valores, usando el identificador de dispositivo IDDtest como dispositivo usado.
Conforme a algunas implementaciones, tras un test con éxito la aplicación software protegida de dispositivo móvil es almacenada en la base de datos (BD) del proveedor de servicios de personalización que está asociada a aplicaciones software protegidas de dispositivo móvil, en relación a los datos de personalización de seguridad que habilitan los uno o más primeros dominios de código para operación regular y a los registros de personalización de seguridad (incluyendo RPS-I).
Conforme a algunas implementaciones, el proceso de test puede también chequear que cuando una personalización/asignación de seguridad errónea es aplicada, DCx/1 y/o DCx/2 no es/son habilitados para operación regular. La figura 2.e ilustra un conjunto de registros de personalización de seguridad (RPSxVD, x= 2, 3, ..., n) con valores por defecto (/erróneos), que pueden ser usados para propósitos de test. En el proceso de test, el parámetro de seguridad psDCs-asignación puede también ser establecido con valores por defecto (/erróneos).
La figura 2.f ilustra una personalización de seguridad que usa los valores por defecto, una vez que ha sido aplicada a la aplicación software protegida de dispositivo móvil. Los siguientes son algunos ejemplos para testear que la personalización de seguridad basada en esos valores por defecto (/erróneos) no habilita la aplicación software protegida de dispositivo móvil para operación regular:
- El valor de psDCs-asignación no corresponde a un parámetro válido para asignar un DCx/1 y CDx/2 dados, o el parámetro es válido pero no está adecuadamente ofuscado, por lo que la reacción de autoprotección programada para tal escenario será aplicada por la aplicación software protegida de dispositivo móvil.
- El valor de psDCs-asignación es correcto y está correctamente ofuscado, y es relativo a la asignación de DCx/1 y DCx/2:
o En un entorno de test, ps^ -rpsxvd ha sido personalizado en formato ofuscado en la parte de la base de datos de la aplicación asociada a CDx/1. Cuando se usa ps^ -rpsxvd la validación asociada a la solicitud para pre registrar un primer servicio en la aplicación software protegida de dispositivo móvil fallará, y el pre registro no será realizado; también, la clave calculada para des ofuscar datos de personalización de seguridad DCx/2 no será correcta, por lo que los valores des ofuscados no serán correctos y una o más reacciones de auto reacción programadas para dicho escenario serán realizadas, según aplique cuando se ejecuten instrucciones de código de DCx/2 que usen esos valores, por la aplicación software protegida de dispositivo móvil.
o En un entorno de test, ch-ib-RPSxVD ha sido personalizada en formato ofuscado en la parte de la base de datos de la aplicación asociada a DCx/1. En este test [ch1a-RSx / ch-ib-RPSxVD] es usado en la verificación de integridad. Si [ch1a-RSx / ch1 b-RPSxVD] es comparado con el calculado por la aplicación software protegida de dispositivo móvil, la verificación fallará y la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
• En la implementación alternativa, referida anteriormente en relación a la figura 2.b, en un entorno de test, ch1b-RPSxVD ha sido personalizadas en formato ofuscado en la parte de la base de datos de la aplicación asociada a DCx/1. En este test el valor establecido en psDCs-asignación hace que una o más partes dadas de [ch1a-RSx / ch1 b-RPSxVD] sean usadas en la verificación de integridad. Si las una o más partes dadas de [ch1a-RSx / ch1b-RPSxVD] son comparadas con la calculada por la aplicación software protegida de dispositivo móvil, la verificación fallará y la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
o En un entorno de test, ro1 b-RPSxVD has sido personalizada en formato ofuscado en una parte de la base de datos de la aplicación asociada a DCx/1. En este test [ro1a-RSx / ro ^ RPSxVD] es usada por la aplicación software protegida de dispositivo móvil para des ofuscar la correspondiente parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas, tal que el proceso de des ofuscación no será correcto y la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
• En una implementación alternativa, referida anteriormente en relación a la figura 2.b, en un entorno de test, ron>RPSxVDha sido personalizada en formato ofuscado en una parte de la base de datos de la aplicación asociada a DCx/1. En este test, el valor establecido en psDCs-asignación hace que una o más partes dadas de [ro1a-RSx / ro-ib-RPSxVD] sean usadas por la aplicación software protegida de dispositivo móvil para des ofuscar la correspondiente parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la correspondiente réplica de la al menos una función fiDCx/1 dada, por lo que el proceso de des ofuscación no será correcto y la reacción de auto protección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
o En un entorno de test, el identificador de dispositivo del dispositivo donde la aplicación ha sido instalada es diferente que IDDtest, por lo que la clave calculada por la aplicación software protegida de dispositivo móvil no será la adecuada para des ofuscar correctamente los datos personalizados de seguridad almacenados en la parte de la base de datos de la aplicación asociada a DCx/1, por lo que la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
o En un entorno de test ps2 b-RPSxVD ha sido personalizada en formato ofuscado en la parte de la base de datos de la aplicación asociada a DCx/2. Cuando se usa ps2 b-RPSxVD la validación asociada a la solicitud para registrar el primer servicio referido anteriormente en la aplicación software protegida de dispositivo móvil fallará, y el registro no será realizado; también, los datos sensibles no estructurados protegidos almacenados en la base de datos de la aplicación software protegida de dispositivo móvil no serán descifrados adecuadamente, por lo que los valores serán incorrectos cuando se utilicen.
o En un entorno de test ch2 b-RPSxVD ha sido personalizado en formato ofuscado en una parte de la base de datos de la aplicación asociada a DCx/2. En este test [ch2 a-RSx / cI ^ -rpsxvd] es usado en la verificación de integridad. Si [ch2 a-RSx / ch2 b-RPSxVD] es comparado con el calculado por la aplicación software protegida de dispositivo móvil, la verificación fallará y la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
• En la implementación alternativa, referida anteriormente en relación a la figura 2.b, en un entorno de test ch2 b-RPSxVD ha sido personalizada en formato ofuscado en la parte de la base de datos de la aplicación asociada a DCx/2. En este test el valor establecido en psDCs-asignación hace que una o más partes dadas de [ch2 a-RSx / ch2 b-RPSxVD] sean usadas en la verificación de integridad. Si las una o más partes dadas de [ch2 a-RSx / cI ^ -rpsxvd] son comparadas con la calculada por la aplicación software protegida de dispositivo móvil, la verificación fallará y la reacción de auto protección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
o En un entorno de test, ro2 b-RPSxVD ha sido personalizada en formato ofuscado en la parte de la base de datos de la aplicación asociada a DCx/2. En este test [ro2 a-RSx / ro2 b-RPSxVD] es usada por la aplicación software protegida de dispositivo móvil para des ofuscar la parte correspondiente del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas, por lo que el proceso de des ofuscación no será correcto y la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
• En la implementación alternativa, referida anteriormente en relación a la figura 2.b, en un entorno de test, ro2 b-RPSxVD ha sido personalizada en formato ofuscado en la parte de la base de datos de la aplicación asociada a DCx/2. En este test, el valor establecido en psDCs-asignación hace que una o más partes dadas de [ro2 a-RSx / ro2 b-RPSxVD] sea usada por la aplicación software protegida de dispositivo móvil para des ofuscar la correspondiente parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la correspondiente réplica de la al menos una función fiDCx/2 dada, por lo que el proceso de des ofuscación no será correcto y la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
o En un entorno de test, al menos parte de psib-RPSxVDserá usado por la aplicación software protegida de dispositivo móvil para calcular la clave para des ofuscar los datos personalizados de seguridad almacenados en la parte de la base de datos de la aplicación asociada a DCx/2. Como se ha detallado anteriormente, usando psib-RPSxVD, chib-RPSxVD, roib-RPSxVD, una o más reacciones de autoprotección definidas ocurrirán y la referida clave para des ofuscar ps2 b-RPSxVD, ch2 b-RPSxVD, ro2 b-RPSxVDno podrá ni siquiera ser calculada.
o En un entorno de test, el identificador de dispositivo del dispositivo donde la aplicación ha sido instalada es diferente que IDDtest, por lo que la clave calculada por la aplicación software protegida de dispositivo móvil no será la adecuada para des ofuscar correctamente los datos personalizados de seguridad almacenados en la parte de la base de datos de la aplicación asociada a DCx/2, por lo que la reacción de autoprotección programada para ese escenario será realizada por la aplicación software protegida de dispositivo móvil.
o Etc.
Otros valores por defecto de personalización de seguridad pueden ser usados para testar más las diferentes posibles asignaciones de dominios de código y configuraciones de seguridad de la aplicación software protegida de dispositivo móvil.
Las reacciones de autoprotección aplicadas pueden ser diversas (ej. la aplicación detiene su ejecución; la aplicación reacciona haciendo que la base de datos de la aplicación sea borrada y/o enviando un mensaje de aviso a través del dispositivo móvil al proveedor de servicios de personalización y/o al correspondiente proveedor de servicios, etc.), y una o más reacciones de autoprotección pueden ser aplicadas a cada medida de protección de la aplicación software protegida de dispositivo móvil.
Una vez que el proceso de test ha finalizado, como se describe en relación a la figura 1 la aplicación software protegida de dispositivo móvil es almacenada en la base de datos (BD) asociada a aplicaciones software protegidas de dispositivo móvil, en relación a los datos de personalización de seguridad que habilitan los uno o más primeros dominios de código para operación regular y a los registros de personalización de seguridad (incluyendo RPS-I).
Después, el módulo de personalización de seguridad obtiene usando uno o más dispositivos de procesamiento la aplicación software protegida de dispositivo móvil de la base de datos. Conforme a algunas implementaciones la aplicación protegida es obtenida sin ningún dato asociado a la personalización de seguridad que habilita los uno o más primeros dominios de código para operación regular, por lo que la aplicación obtenida es una aplicación software protegida de dispositivo móvil no personalizada en seguridad. La aplicación software protegida de dispositivo móvil no personalizada en seguridad está en un estado de personalización de seguridad pendiente, dicho estado de personalización de seguridad pendiente deshabilitando los uno o más primeros dominios de código para operación regular.
Como también se describe en la figura 1, la aplicación software protegida de dispositivo móvil es enviada en un estado de seguridad no-personalizada desde el proveedor de servicios de personalización a un servidor de distribución de una entidad a cargo de distribuir la aplicación y dicha aplicación es almacenada en una o más memorias del servidor de distribución de dicha entidad. Conforme a algunas implementaciones el servidor de distribución es relativo a uno o más de los servidores asociados a un mercado de distribución de aplicaciones o una tienda de aplicaciones tales como Google Play Store o Apple Store.
Después, a partir de interacción del usuario el teléfono móvil del usuario solicita una aplicación software de dispositivo móvil al servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada.
En el siguiente paso el dispositivo móvil del usuario recibe desde el servidor de distribución y subsecuentemente instala usando uno o más dispositivos de procesamiento en el dispositivo móvil la aplicación software protegida de dispositivo móvil no personalizada en seguridad, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código están deshabilitados para operación regular.
Ventajosamente, cuando la aplicación software protegida de dispositivo móvil es descargada desde el servidor de distribución y es instalada en el dispositivo móvil del usuario, la aplicación software protegida de dispositivo móvil está en un estado de seguridad no-personalizada donde los uno o más primeros dominios de código están deshabilitados para operación regular, por lo que la aplicación se auto protegerá contra intentos de ej. realizar ejecuciones de código según se ha explicado extensamente en conexión a algunas de las figuras previas.
Las figuras 2.g a 2.l son relativas a algunas implementaciones donde la aplicación software protegida de dispositivo móvil instalada en el dispositivo móvil del usuario 1 es personalizada en términos de seguridad usando un primer registro de personalización de seguridad de ciclo de vida, y la aplicación software protegida de dispositivo móvil instada en el dispositivo móvil del usuario 2 es personalizada en términos de seguridad usando un segundo registro de personalización de seguridad de ciclo de vida, ambos el primer y el segundo registros de personalización de seguridad de ciclo de vida siendo diferentes que el registro de personalización de seguridad de inicialización (RPS-I en los ejemplos anteriores).
En estas implementaciones cada registro de personalización de seguridad de ciclo de vida está asociado en el sistema del proveedor de servicios de personalización a un conjunto de primeros y segundos dominios de código de la siguiente forma:
- Cada uno de los RPS2j (j= 2 to N), está asociado a los primeros dominios de código DC2/1 y DC2/2 y al segundo dominio de código CD1;
- Cada uno de los RPS3j (j= 2 to N), está asociado a los primeros dominios de código DC3/1 y DC3/2 y al segundo dominio de código CD1;
- Cada uno de los RPS4j (j= 2 to N), está asociado a los primeros dominios de código DC4/1 y DC4/2 y al segundo dominio de código CD1;
- Cada uno de los RPSij (j= 2 to N), está asociado a los primeros dominios de código DCi/1 y DCi/2 y al segundo dominio de código CD1;
- Cada uno de los RPSnj (j= 2 to N), está asociado a los primeros dominios de código DCn/1 y DCn/2 y al segundo dominio de código CD1;
y la asociación es almacenada en la base de datos asociada a aplicaciones software protegidas de dispositivo móvil.
Como se describe en relación al paso (8) de la figura 1, el dispositivo móvil del usuario envía una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada, la solicitud incluyendo un identificador del dispositivo móvil del usuario (IDDusuario). En el paso (9) el proveedor de servicios de personalización recibe la solicitud desde el dispositivo móvil del usuario y en el paso (10) uno o más dispositivos de procesamiento del proveedor de servicios de personalización asignan un registro de personalización de seguridad de ciclo de vida al dispositivo móvil del usuario (IDDusuario) en relación a la aplicación software protegida de dispositivo móvil.
La figura 2.g es primero relativa a un escenario donde la aplicación software protegida de dispositivo móvil es instalada en el dispositivo móvil del usuario 1 (con IDDusuario1), y los pasos (8), (9) y (10) tienen lugar en relación a dicho dispositivo móvil del usuario 1. En el ejemplo ilustrado en la figura 2.g el registro de personalización de seguridad de ciclo de vida asignado por el módulo de personalización de seguridad al dispositivo móvil del usuario 1 es RPS43, que como se ha referido anteriormente está asociado a DC4/1, DC4/2 y DC1. Todavía en el paso (10) la asignación del registro de personalización de seguridad de ciclo de vida RPS43 al dispositivo móvil del usuario 1 y a la aplicación software protegida de dispositivo móvil es almacenada en la base de datos asociada a aplicaciones software protegidas de dispositivo móvil.
En más detalle, conforme a algunas implementaciones el módulo de personalización de seguridad puede realizar las siguientes asignaciones y preparación de datos en el paso (10) (algunos de los procesos de preparación de datos pueden también ser realizados en una fase posterior, antes de enviar los datos a la aplicación software protegida de dispositivo móvil), in relación al dispositivo móvil del usuario 1 y a la personalización de seguridad:
- Asignación de RPS43 en el contexto del proceso de personalización de seguridad en curso, asociado a DC4/1, DC4/2 y DC1 y a IDDusuarioi;
- Asignar a psDCs-asignación un valor de dato asociado a DC4/1 y DC4/2 tal que, una vez personalizado en seguridad, la aplicación software protegida de dispositivo móvil use DC4/1, DC4/2 y DC1 durante su ejecución. En estas implementaciones el valor de dato está ofuscado usando un método que usa un parámetro de seguridad que está embebido en una función de DC1 y al menos parte del IDDusuarioi.
- Ofuscación de [psn>RPS43 , roib-RPS43 , chib-RPS43 ] usando un algoritmo de ofuscación y la clave de ofuscación para proteger datos de personalización de seguridad CD4/1, como se ilustra en la figura 2.g (en este proceso de personalización de seguridad x = 4). En estas implementaciones:
o Los primeros 10 dígitos de IDDusuarioi son parte de la clave de ofuscación;
o [psia-RS4 , psib-RPS43 ] se convierten en las dos partes del mismo parámetro de seguridad:
• Una o más partes de [psia-RS4 , psib-RPS43 ] serán usadas para validar que una solicitud para pre registrar un primer servicio, asociado al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario i (con IDDusuarioi) y ha sido lanzada desde DC4/1 con la personalización de seguridad adecuada;
• Otras una o más partes del parámetro de seguridad [psia-RS4 / psib-RPS43 ] serán usadas para proteger datos en ciertas partes de la base de datos de la aplicación software protegida de dispositivo móvil (en este contexto, ciertas partes asociadas a DC4/1 y DC4/2). En estas implementaciones, dichas otras una o más partes del parámetro de seguridad son usadas para proteger al menos parte de la parte de la base de datos de la aplicación que no está asociada a personalización / asignación de seguridad de dominios de código.
Cuando la aplicación software protegida de dispositivo móvil recibe datos para almacenamiento en la al menos parte de la parte de la base de datos que no está asociada a personalización / asignación de seguridad de dominios de código, esos son cifrados usando las referidas otras una o más partes del parámetro de seguridad [ps1a-RS4 / psib-RPS43 ], antes de ser almacenados en la correspondiente al menos parte de la parte de la base de datos de la aplicación.
• Otras una o más partes del parámetro de seguridad [ps1a-RS4 / psib-RPS43 ] son asignadas como el parámetro de seguridad que es parte de la clave de ofuscación usada para ofuscar [ps2 b-RPS43], [ch2b-RPS43] y [ro2b-RPS43].
o [chi1a-SR4 , ch1 b-SPR43 ] se convierten en las dos partes de la misma red de checksums, que será usada para verificar la integridad de partes del código de la aplicación de las funciones DC4/1(f1 DC4 / 1 , f2 üC4 /i, ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/1(flDC4/i, f2DC4/i,...).
• En estas implementaciones chib-RPS43 = chib-RPS4 i ;
• Conforme a algunas implementaciones alternativas chib-RPS43 = chib-RPS4 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la red de checksums [chia-RS4 / chib-RPS43 ] serán usadas para verificar la integridad de partes del código de la aplicación de las funciones D C 4/i(fiDC4/i, f2DC4/i, ■■■) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/i(fi DC4/i, f2DC4/i, ■■■);
o [roia-RS4 , roib-RPS43 ] se convierten en las dos partes de la misma regla de ofuscación, que es usada para ofuscar parte del código de la aplicación de las funciones D C 4/i(fiDC4/i, f2DC4/i,...) junto con parte de los [psia-RS4, ps3-RS4, ps4-RS4.... psi-RS4] y parte de los [chia-RS4, ch3-RS4, cIv rs4.... chi-RS4] embebidos en el código de la aplicación de las funciones D C 4/i(fiDC4/i, f2DC4/i, ■■■).
• En estas implementaciones roib-RPS43 = roib-RPS4 i ;
• Conforme a algunas implementaciones alternativas roib-RPS43 = roib-RPS4i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [roia-RS4 / roib-RPS43 ] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la réplica de la función fioo4 /i en DC4/i que está asociada al valor dado del parámetro.
- Ofuscación de [ps2b-RPS43, ro2b-RPS43, ch2b-RPS43] usando un algoritmo de ofuscación y la clave de ofuscación para proteger datos de personalización de seguridad DC4/2, como se ilustra en la figura 2.g (en este proceso de personalización de seguridad x = 4). En estas implementaciones:
o El parámetro de seguridad que es parte de la clave de ofuscación está constituido por al menos parte de [psia-RS4 ] y al menos parte de [psib-RPS43 ]. Los primeros i0 dígitos de IDDusuarioi son también parte de la clave de ofuscación;
o [ps2 a-RS4 , ps2 b-RPS43 ] se convierten en las dos partes del mismo parámetro de seguridad:
• Una o más partes de [ps2 a-RS4 , ps2 b-RPS43 ] serán usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC4/2 tras un pre registro previo con éxito del primer servicio), asociado al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario i (con IDDusuarioi) y ha sido lanzada desde DC4/2 con la personalización de seguridad adecuada;
• Otras una o más partes del parámetro de seguridad [ps2 a-RS4 / ps2 b-RPS43 ] serán usadas para proteger ciertos datos sensibles no estructurados antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario i (ej.
para proteger claves/datos sensibles necesarios para que la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1 calcule credenciales dinámicas asociadas a servicios provistos por el proveedor de servicios 1; ej. protección de claves de sesión), cuando psDCs-asignación es establecido al valor asociado a DC4/1 y DC4/2.
• Otras una o más partes del parámetro de seguridad [ps2a-RS4 / ps2b-RPS43] serán usadas por la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1 para ofuscar ciertos datos sensibles, en el contexto de la ejecución de algunas instrucciones de código DC4/2, para evitar que sean expuestas en claro en una o más memorias de trabajo del dispositivo móvil, cuando psDCs-asignación es establecido al valor asociado a DC4/1 y DC4/2.
o [chi2a-RS4, ch2b-RPS43] se convierten en las dos partes de la misma red de checksums, que será usada para verificar la integridad de partes del código de la aplicación de las funciones DC4/2(f1 DC4/2, f2 DC4/2, ■ ■ ) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/2(flDC4/2, f2 DC4/2, ...).
• En estas implementaciones ch2b-RPS43 = ch2b-RPS4i;
• Conforme a algunas implementaciones alternativas ch2 b-RPS43 = ch2 b-RPS4 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la red de checksums [chi2 a-RS4 / ch2 b-RPS43 ] serán usadas para verificar la integridad de partes del código de la aplicación de las funciones DC4/2(flDC4/2, f2 DC4 /2 , ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/2(f1 DC4/2, f2DC4/2, ...);
o [ro2 a-RS4 , ro2 b-RPS43 ] se convierten en las dos partes de la misma regla de ofuscación, que son usadas para ofuscar parte del código de la aplicación de las funciones DC4/2(flDC4/2, f2 DC4 /2 , ...) junto con parte de los [ps2a-RS4, ps0+i)-RS4, ps(i+2)-RS4..., psq-RS4] y parte de los [ch2a-RS4, ch0+i)-RS4, ch(i+2 )-RS4 ..., chq-RS4 ] embebidos en el código de la aplicación de las funciones DC4/2(f1 dc4/2 , f 2 DC4 /2 ...).
• En estas implementaciones ro2b-RPS43 = ro2b-RPS4i;
• Conforme a algunas implementaciones alternativas ro2b-RPS43 = ro2b-RPS4i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro2a-RS4 / ro2b-RPS43] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la réplica de la función fiDC4/2 en DC4/2 que está asociada al valor dado del parámetro.
Estas asignaciones y datos preparados son almacenados en la base de datos asociada a aplicaciones software protegidas de dispositivo móvil, en relación al dispositivo móvil del usuario i, la aplicación software protegida de dispositivo móvil y el proceso de personalización de seguridad.
En el paso ( i i ) de la figura i al menos parte del registro de personalización de seguridad de ciclo de vida asignado, y la asociación al dispositivo móvil del usuario y a la aplicación software protegida de dispositivo móvil es enviada al proveedor de servicios correspondiente tal que pueda usar al menor parte de ello en el contexto de ciertos procesos de ciclo de vida de la aplicación software protegida de dispositivo móvil. Conforme a algunas implementaciones (en relación a la figura 2.g) al menos parte de las asignaciones y datos asociados al dispositivo móvil del usuario i y a la personalización de seguridad de la aplicación software protegida de dispositivo móvil son enviados al proveedor de servicios i para almacenamiento y/o para uso de al menos parte de ello en el contexto de ciertos procesos de ciclo de vida de la aplicación software protegida de dispositivo móvil asociada al dispositivo móvil del usuario i. En un ejemplo particular:
• Las una o más partes de [psia-RS4 , psib-RPS43] que serán usadas para validar que una solicitud para pre registrar un primer servicio, asociado al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario i (con IDDusuarioi) y ha sido lanzada desde DC4/i con la personalización de seguridad adecuada y;
• Las una o más partes de [ps2a-RS4, ps2b-RPS43] que serán usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC4/2 tras un pre registro previo con éxito del primer servicio), asociado al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 1 (con IDDusuario1) y ha sido lanzada desde DC4/2 con la personalización de seguridad adecuada;
son enviadas al proveedor de servicios 1 para almacenamiento y para uso durante el proceso de pre registro y de registro, respectivamente, de un primer servicio en la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1.
En el paso (12) de la figura 1 datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida asignado son enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario. En particular, datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario son enviados a la aplicación software protegida de dispositivo móvil no personalizada en seguridad en el dispositivo móvil del usuario. Conforme a algunas implementaciones (en relación a la figura 2.g) [psib-RPS43 , roib-RPS43 , chib-RPS43 ] son enviados en formato ofuscado a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1.
En el paso (13) de la figura 1 el dispositivo móvil del usuario recibe los datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones la habilitación de el al menos uno de los uno o más primeros dominios de código está asociada a uno o más parámetros de seguridad relativos al registro de personalización de seguridad de ciclo de vida (ej. psib-RPS43 relativo al registro de personalización de seguridad de ciclo de vida RPS43), que son diferentes que los correspondientes del registro de personalización de seguridad (ej. psibrps2 i , psib-RPS3i, psib-RPS4i, ■■■, psib-RPSii, .... psib-RPSni en relación a RPS-I).
Conforme a algunas implementaciones (en relación a la figura 2.g) el dispositivo móvil del usuario i recibe en formato ofuscado (la ofuscación usando un método que usa un parámetro de seguridad que está embebido en una función de DC1 y al menos parte de IDDusuarioi) el valor de dato para almacenamiento en la parte de la aplicación software protegida de dispositivo móvil asociada a psoCs-asignación, dicho valor haciendo que la aplicación software protegida de dispositivo móvil use DC4/1, DC4/2 y DC1 durante su ejecución. En estas implementaciones el dispositivo móvil del usuario i también recibe [psib-RPS43 , roib-RPS43 , chib-RPS43 ] en formato ofuscado desde el proveedor de servicios de personalización y estos son almacenados en la parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a DC4/1 (como se ilustra en la figura 2.h). Los datos de personalización de seguridad [psib-RPS43, roib-RPS43, chib-RPS43] recibidos y almacenados habilitan el primer dominio de código DC4/1 para operación regular, la ofuscación de dichos datos siendo relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en el segundo dominio de código DC1 y que son requeridos para habilitar el primer dominio de código DC4/1 para operación regular, como se ha descrito en relación a la figura 2.d.
Ventajosamente, después de que la personalización de seguridad anterior haya sido realizada, el referido al menos uno de los uno o más primeros dominios de código pueden ser usados para realizar regularmente las funciones asociadas de ciclo de vida de la aplicación.
Durante su ciclo de vida la aplicación software protegida de dispositivo móvil será capaz de des ofuscar psocsasignacióny de determinar que DC4/1, DC4/2 y DC1 deben ser usados durante su ejecución. También, la aplicación software protegida de dispositivo móvil será capaz de des ofuscar [psib-RPS43 , roib-RPS43 , chib-RPS43 ] usando el algoritmo de ofuscación y la clave de ofuscación que protege datos de personalización de seguridad DC4/1, como ya se ha ilustrado en relación a la figura 2.g (x = 4). Más en detalle:
- Para solicitar el pre registro de un primer servicio, una o más partes de [psia-RS4 / psib-RPS43 ] son des ofuscadas por la aplicación software protegida de dispositivo móvil, y un cálculo basado en las una o más partes des ofuscadas de [psia-RS4 / psib-RPS43 ] es enviado al proveedor de servicios i para verificación de que la solicitud es enviada desde el dispositivo apropiado y ha sido lanzada desde el dominio de código adecuado (DC4/1) con la correcta personalización de seguridad. Como se ha referido anteriormente, el proveedor de servicios i ha almacenado previamente las una o más partes de [psia-RS4 / psib-RPS43 ] en relación al dispositivo móvil del usuario i , para usarlas durante el proceso de verificación.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [spia-RS4 / spib-RPS43] son usadas para proteger al menos parte de la parte de la base de datos de la aplicación asociada a DC4/1 y DC4/2 (y no asociada a personalización / asignación de seguridad de dominios de código). Cuando la aplicación software protegida de dispositivo móvil requiere del uso de datos almacenados en dicha al menos parte de la parte de la base de datos, las otras una o más partes del parámetro de seguridad [ps1a-RS4 / ps1b-RPS43] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar los datos en la base de datos, para uso.
- Otras una o más partes del parámetro de seguridad [ps1a-RS4 / ps1b-RPS43] serán des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para calcular la clave de ofuscación para des ofuscar [ps2b-RPS43], [ch2b-RPS43] y [ro2b-RPS43], cuando sea requerido.
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ch1a-RS4 , ch1b-RPS43 ] serán usados para verificar la integridad de las partes relativas del código de la aplicación de las funciones DC4/1(f1 DC4 / 1 , f2üC4/1, ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/1(f1DC4/1, f2DC4/1, ■■■). Cuando la aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [ch1a-RS4 , ch1 b-RPS43 ] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. Como se ha referido anteriormente, en estas implementaciones ch1 b-RPS43 = ch1 b-RPS41 ;
• Conforme a las implementaciones alternativas referidas anteriormente, ch1b-RPS43 = ch1 b-RPS41 y un parámetro en psDCs-asignación ha sido establecido a un valor dado tal que una o más partes asociadas de la red de checksums [ch1a-RS4 / ch1b-RPS43 ] serán usadas para verificar la integridad de partes relativas del código de la aplicación de las funciones DC4/1(f1DC4/1, f2 oo4 /1 , ■■■) y de al menos partes relativas de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/1(f1 DC4/1, f2DC4/1, ■■■);
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ro1a-RS4 , ron>RPS43 ] será usada para des ofuscar la parte relativa del código de la aplicación de las funciones DC4/1(f1DC4/1, f2 DC4 /1 , ...), la parte relativa de los [ps1a-RS4 , ps3-RS4 , ps4 -RS4 ..., psi-RS4 ] y la parte relativa de los [ch1a-RS4 , ch3-RS4 , chi4-RS4..., chi-RS4] embebidos en el código de la aplicación de las funciones DC4/1(f1DC4/1, f2DC4/1, ...). Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha parte referida del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos, el correspondiente proceso de des ofuscación es aplicado usando [ro1a-RS4 / ro1 b-RPS43 ]. Como se ha referido anteriormente, en estas implementaciones ron>RPS43 = ro1 b-rps41 ;
• Conforme a las implementaciones alternativas referidas anteriormente ro1b-RPS43 = orn>RPS41 y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro1a-RS4 / ro1 b-RPS43 ] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos de la réplica de la función fiDC4 /1 en DC4/1 que está asociada al valor dado del parámetro cuando la aplicación software protegida de dispositivo móvil requiere el uso de dicha parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos.
En referencia nuevamente a la figura 1, conforme a algunas implementaciones diferentes grupos de uno o más primeros dominios de código no-habilitados son personalizados en términos de seguridad en diferentes instantes de tiempo. Esta aproximación incrementa la seguridad de la aplicación software protegida de dispositivo móvil.
En las implementaciones descritas en las figuras 2.a a 2.l, DCx/2 son otros primeros dominios de código. Los pasos (14a) a (14e) descritos a continuación son relativos a la aplicación software protegida de dispositivo móvil instalada en el dispositivo móvil del usuario 1, el registro de personalización de seguridad de ciclo de vida asignado es RPS43 y psDCs-asignación tiene un valor de dato asignado asociado a DC4/1 y DC4/2, por lo que en este contexto DC4/2 es el otro primer dominio de código.
También, por simplicidad, en el contexto de las figuras 2.a a 2.l, los pasos (15a) a (15e) y los pasos (16a) a (16e) no tienen lugar.
Tal y como ya se ha descrito en la figura 1, el paso (14a) representa una solicitud sucesiva para una personalización de seguridad de al menos otro uno o más primeros dominios de código, enviada desde el dispositivo móvil del usuario al proveedor de servicios de personalización (en el contexto actual: una personalización de seguridad de DC4/2 enviada desde el dispositivo móvil del usuario 1).
En estas implementaciones, cada solicitud de dispositivo móvil de usuario es lanzada por uno o más dispositivos de procesamiento usando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular (en el contexto actual: eso es código ejecutable perteneciente a DC4/1, la solicitud lanzada desde el dispositivo móvil del usuario 1).
En el paso (14a) de la figura 1 una solicitud sucesiva es enviada desde el dispositivo móvil del usuario 1 al proveedor de servicios de personalización y en el paso (14b) el proveedor de servicios de personalización recibe la solicitud sucesiva desde el dispositivo móvil del usuario 1, y uno o más dispositivos de procesamiento del proveedor de servicios de personalización pueden obtener en el paso (14c) datos de personalización de seguridad ([ps2 b-RPS43 , ro2 b-RPS4 3 , ch2 b-RPS43 ]) desde el registro de personalización de seguridad de ciclo de vida previamente asignado al dispositivo móvil del usuario (desde RPS43). Conforme a algunas implementaciones los datos de personalización de seguridad han sido previamente obtenidos del registro de personalización de seguridad: esto puede ser realizado ej. en el paso (10), donde como se ha descrito anteriormente ([ps2 b-RPS43 , ro2 b-RPS43 , ch2 b-RPS43 ] han sido almacenados en formato ofuscado en la base de datos asociada a aplicaciones software protegidas de dispositivo móvil, en relación al dispositivo móvil del usuario 1, la aplicación software protegida de dispositivo móvil y el proceso de personalización de seguridad.
En el paso (14d) de la figura 1 los datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida RPS43 previamente asignado al dispositivo móvil del usuario 1 son enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario 1. En particular, datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida (RPS43) son enviados a la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad. Conforme a algunas implementaciones (en relación a la figura 2.g) [ps2 b-RPS43 , ro2 b-RPS43 , ch2 b-RPS43 ] son enviados en formato ofuscado a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1.
En el paso (14e) de la figura 1 el dispositivo móvil del usuario 1 recibe desde el proveedor de servicios de personalización los datos de personalización de seguridad ([ps2 b-RPS43 , ro2 b-RPS43 , ch2 b-RPS43 ] en formato ofuscado) asociados al registro de personalización de seguridad de ciclo de vida (RPS43) relativo al dispositivo móvil del usuario 1 en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos son almacenados en la parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a DC4/2 (como se ilustra en la figura 2.i), los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código (DC4/2) que está asociado a la solicitud particular.
Conforme a algunas implementaciones, al menos uno del otro uno o más primeros dominios de código (DC4/2) está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código (DC4/1) a través de la personalización de seguridad ([ps2 b-RPS43 , ro2 b-RPS43 , ch2 b-RPS43 ]), dicha personalización relativa a parámetros de seguridad (al menos parte de [ps1a-RS4 , ps1b-RPS43 ]) y/o reglas de ofuscación (al menos parte de [ro1a-RS4 , ron>RPS43 ]) y/o datos de checksums de código (al menos parte de [ch1ars4 , ch1b-RPS43 ]) que están al menos parcialmente disponibles en los uno o más primeros dominios de código (DC4/1) y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones, al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario y están disponibles en una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a uno o más primeros dominios de código que han sido previamente habilitados para operación regular ([ps1 b-RPS43 ]) y/o [ro1b-RPS43 ]) y/o [ch1b-RPS43 ] están disponibles en una parte de la base de datos de la aplicación que está asociada a DC4/1).
Ventajosamente, una vez que la personalización de seguridad anterior ha sido realizada, el referido al menos otro uno o más primeros dominios de código puede ser usado para realizar regularmente las funciones asociadas de ciclo de vida de la aplicación.
Durante su ciclo de vida la aplicación software protegida de dispositivo móvil será capaz de des ofuscar [ps2 brps43 , ro2 b-RPS43 , ch2 b-RPS43 ] usando el algoritmo de ofuscación y la clave de ofuscación que protege datos de personalización de seguridad DC4/2, como ya se ha ilustrado en relación a la figura 2.g (x = 4). Más en detalle: - Para solicitar el registro del primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC4/2 tras un pre registro previo con éxito del primer servicio), una o más partes de [ps2 a-RS4 / ps2 b-RPS43 ] son des ofuscadas por la aplicación software protegida de dispositivo móvil, y un cálculo basado en las des ofuscadas una o más partes de [ps2 a-RS4 / ps2 b-RPS43 ] es enviado al proveedor de servicios 1 para verificación de que la solicitud es enviada desde el dispositivo apropiado y ha sido lanzada desde el dominio de código adecuado (DC4/2) con la personalización de seguridad adecuada. Como se ha referido anteriormente, el proveedor de servicios 1 ha almacenado previamente las una o más partes de [ps2a-RS4 / ps2 b-RPS43 ] en relación al dispositivo móvil del usuario 1, para usarlas durante el proceso de verificación.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [ps2 a-RS4 / ps2 b-RPS43] son usadas para proteger ciertos datos sensibles no estructurados antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1. Conforme a algunas implementaciones cuando la aplicación software protegida de dispositivo móvil requiere el uso de al menos parte de los datos sensibles no estructurados, las otras una o más partes del parámetro de seguridad [ps2 a-RS4 / ps2 b-RPS43 ] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar los al menos parte de los datos sensibles no estructurados almacenados, para uso.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [ps2 a-RS4 / ps2 b-RPS43 ] son usadas para ofuscar ciertos datos sensibles, en el contexto de la ejecución de algunas instrucciones de código DC4/2, para evitar que sean expuestos en claro en una o más memorias de trabajo del dispositivo móvil del usuario 1. Cuando, durante la ejecución de ciertas instrucciones de código DC4/2, uno o más dispositivos de procesamiento en el dispositivo móvil del usuario 1 requieren usar los datos sensibles ofuscados previamente almacenados en las una o más memorias de trabajo, estos utilizan las otras una o más partes de [ps2 a-RS4 / ps2 b-RPS43 ] (y la regla de ofuscación referida anteriormente en relación a la figura 2.b) para obtener los datos adecuados para el relativo cálculo/proceso.
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ch2 a-RS4 , ch2 b-RPS43 ] será usado para verificar la integridad de las partes relativas del código de la aplicación de las funciones DC4/2(f1 DC4 / 2 , f2üC4/2, ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/2(f1DC4/2, f2DC4/2, ...). Cuando la aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [ch2 a-RS4 , ch2 b-RPS43 ] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. Como se ha referido anteriormente, en estas implementaciones ch2 b-RPS43 = ch2 b-RPS41 i
• Conforme a las implementaciones alternativas referidas anteriormente, ch2 b-RPS43 = ch2 b-RPS41 y un parámetro en psDCs-asignación ha sido establecido a un valor dado tal que una o más partes asociadas de la red de checksums [ch2 a-RS4 / ch2 b-RPS43 ] serán usadas para verificar la integridad de partes relativas del código de la aplicación de las funciones DC4/2(f1DC4/2, f2 DC4 /2 , ...) y de al menos partes relativas de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC4/2(f1 DC4/2, f2DC4/2, ■■■)!
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ro2a-RS4, ro2b-RPS43] será usada para des ofuscar la parte relativa del código de la aplicación de las funciones DC4/2(f1 dc4/2, Ó dc4/2, ...), la parte relativa de los [ps2a-RS4, ps(i+1)-RS4, ps(i+2)-RS4..., psq.RS4] y la parte relativa de los [ch2a-RS4, ch(i+1>. rs4, ch(i+2)-RS4..., chq-RS4] embebidos en el código de la aplicación de las funciones DC4/2(f1DC4/2, f2 DC4/2, ...). Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha referida parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas, el correspondiente proceso de des ofuscación es aplicado usando [ro2a-RS4 / ro2b-RPS43]. Como se ha referido anteriormente, en estas implementaciones ro2b-RPS43 = ro2b-RPS41;
• Conforme a las implementaciones alternativas referidas anteriormente ro2b-RPS43 = ro2b-RPS41 y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro2a-RS4 / ro2b-RPS43] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos de la réplica de la función fiDC4/2 en DC4/2 que está asociada al valor dado del parámetro cuando la aplicación software protegida de dispositivo móvil requiere el uso de dicha parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas.
En un ejemplo particular los procesos incluyendo hasta el paso 13 ya han sido realizados tal que la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1 está en un estado parcialmente personalizado de seguridad. Como se ha descrito anteriormente, en el paso (14a) una solicitud sucesiva es enviada desde el dispositivo móvil del usuario 1 y recibida en el paso (14b) por el proveedor de servicios de personalización. En este ejemplo, al inicio del paso (14c), uno o más dispositivos de procesamiento del proveedor de servicios de personalización verifican si la solicitud ha sido recibida (paso 14b) más tarde que un periodo predefinido de tiempo después de que datos de personalización de seguridad fueran enviados a la aplicación software protegida de dispositivo móvil en el paso (12).
Si la solicitud ha sido recibida más tarde que dicho periodo predefinido de tiempo, entonces la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad asociada al dispositivo móvil del usuario 1 expira en el sistema del proveedor de servicios de personalización. Conforme a algunas implementaciones, el proveedor de servicios de personalización notifica (no ilustrado en la figura 1) al proveedor de servicios 1 acerca del estado de expiración de la aplicación software protegida de dispositivo móvil asociada al dispositivo móvil del usuario 1. También, una notificación indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado es enviada al dispositivo móvil del usuario 1 y recibida en el dispositivo móvil del usuario 1.
Por tanto, conforme a algunas implementaciones uno o más dispositivos de procesamiento en el sistema del proveedor de servicios de personalización hacen una aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad expirar si una solicitud para una personalización de seguridad de al menos otro uno o más primeros dominios de código (ej. DC4/2) es recibida más tarde que un periodo de tiempo predefinido después de que datos de personalización de seguridad relativos a una solicitud previa para una personalización de seguridad de al menos uno (ej. DC4/1) u otro diferente uno de los uno o más primeros dominios de código fueran enviados a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada o parcialmente-personalizada. Esta aproximación incrementa adicionalmente la seguridad de la aplicación software protegida de dispositivo móvil.
También, conforme a algunas implementaciones, una notificación desde el proveedor de servicios de personalización indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado es enviada al dispositivo móvil del usuario 1 y recibida en el dispositivo móvil del usuario 1.
Conforme a algunas implementaciones:
- [ps1b-RPS43 , ro1 b-RPS43 , ch1b-RPS43 ] en formato ofuscado son enviadas a (paso (12)) y almacenadas en (paso (13) la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 1. Los datos de personalización de seguridad [ps1b-RPS43 , ro1b-RPS43 , ch1 b-RPS43 ] recibidos y almacenados habilitan el primer dominio de código CD4/1 para operación regular.
- Una o más partes de [ps1a-RS4 , ps1 b-RPS43 ] serán posteriormente usadas para validar que una solicitud para pre registrar un primer servicio, asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 1, y ha sido lanzada desde DC4/1 con la personalización de seguridad adecuada. En un ejemplo particular el usuario 1 obtiene un código de activación y este es enviado en el contexto del proceso de pre registro del primer servicio, desde el dispositivo móvil del usuario 1 al proveedor de servicios de personalización, para validación. En un ejemplo particular los pasos (14a) a (14e) son también realizados en el contexto del proceso de pre registro del primer servicio (ej. tras una validación con éxito del código de activación referido en el ejemplo previo), por lo que [ps2 b-RPS43 , ro2 b-RPS43 , ch2 b-RPS43 ] serán recibidos y almacenados en formato ofuscado en la parte de la base de datos de la aplicación asociada a DC4/2 antes de que el proceso de pre registro del primer servicio finalice.
- Una o más partes de [ps2 a-RS4 , ps2 b-RPS43 ] serán más tarde usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC4/2 tras un pre registro previo con éxito del primer servicio), asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 1 y ha sido lanzada desde DC4/2 con la personalización de seguridad adecuada.
En un ejemplo particular un PIN (Número de Identificación Personal) es seleccionado por el usuario 1 e insertado en el dispositivo móvil del usuario 1 durante el proceso de registrar dicho primer servicio en la aplicación software protegida de dispositivo móvil y datos enviados a y almacenados en la base de datos de la aplicación software protegida de dispositivo móvil durante el proceso de pre registro de dicho primer servicio son usados para autenticar el registro del PIN seleccionado en el sistema del proveedor de servicios 1 (ej. dichos datos pueden permitir calcular una credencial dinámica basada-en-PlN que puede ser autenticada por el proveedor de servicios de personalización, así asegurando que el cálculo ha sido realizado desde el dispositivo móvil del usuario 1 y ej. por funciones en DC4/2, con la personalización de seguridad adecuada aplicada).
Si las validaciones tienen éxito el proceso de registro puede concluir con éxito (ej. enviando datos asociados al proceso de registro del primer servicio al dispositivo móvil del usuario 1).
Conforme a algunas implementaciones, adicionalmente a establecer un límite de tiempo entre los pasos (12) y (14b) para que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad expire, otro límite de tiempo asociado al total del proceso de pre registro y de registro del primer servicio en la aplicación software protegida de dispositivo móvil puede ser establecido, una vez que la aplicación software protegida de dispositivo móvil ya está en un estado de personalización parcial de seguridad. Ventajosamente, esos límites de tiempo pueden incrementar la seguridad del sistema.
La figura 2.g es también relativa a un escenario donde la aplicación software protegida de dispositivo móvil es instalada en el dispositivo móvil del usuario 2 (con IDDusuario2 ), y los pasos (8), (9) y (10) tienen lugar en relación a dicho dispositivo móvil del usuario 2. En el ejemplo ilustrado en la figura 2.g el registro de personalización de seguridad de ciclo de vida asignado por el módulo de personalización de seguridad al dispositivo móvil del usuario 2 es RPS32, que tal y como se ha referido anteriormente está asociado a DC3/1, DC3/2 y DC1. Todavía en el paso (10) la asignación del registro de personalización de seguridad de ciclo de vida RPS32 al dispositivo móvil del usuario 2 y a la aplicación software protegida de dispositivo móvil es almacenada en la base de datos asociada a aplicaciones software de dispositivo móvil.
En más detalle, conforme a algunas implementaciones el módulo de personalización de seguridad puede realizar las siguientes asignaciones y preparación de datos en el paso (10) (algunos de los procesos de preparación de datos pueden también ser realizados en una fase posterior, antes de enviar los datos a la aplicación software protegida de dispositivo móvil), in relación al dispositivo móvil del usuario 2 y a la personalización de seguridad:
- Asignación de RPS32 en el contexto del proceso de personalización de seguridad en curso, asociado a DC3/1, DC3/2 y CD1 y a IDDusuario2 ;
- Asignar a psDCs-asignación un valor de dato asociado a DC3/1 y DC3/2 tal que, una vez personalizado en términos de seguridad, la aplicación software protegida de dispositivo móvil usará DC3/1, DC3/2 y DC1 durante su ejecución. En estas implementaciones el valor de dato es ofuscado usando un método que usa un parámetro de seguridad que está embebido en una función DC1 y al menos parte de IDDusUARIO2.
- Ofuscación de [psn>RPS32 , ro1 b-RPS32 , ch1 b-RPS32 ] usando un algoritmo de ofuscación y la clave de ofuscación para proteger datos de personalización de seguridad DC3/1, como se ilustra en la figura 2.g (en este proceso de personalización de seguridad x = 3). En estas implementaciones:
o los primeros 10 dígitos de IDDusuario2 son parte de la clave de ofuscación;
o [ps1a-RS3 , ps1 b-RPS32 ] se convierten en las dos partes del mismo parámetro de seguridad:
• Una o más partes de [ps1a-RS3 , psn>RPS32 ] serán usadas para validar que una solicitud para pre registrar un primer servicio, asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con Id Dusuario2 ) y ha sido lanzada desde DC3/1 con la personalización de seguridad adecuada;
• Otras una o más partes del parámetro de seguridad [ps1a-RS3 / ps1b-RPS32 ] serán usadas para proteger datos en ciertas partes de la base de datos de la aplicación software protegida de dispositivo móvil (en este contexto, ciertas partes asociadas a DC3/1 y DC3/2). En estas implementaciones, dichas otras una o más partes del parámetro de seguridad son usadas para proteger al menos parte de la parte de la base de datos de la aplicación que no está asociada a personalización / asignación de seguridad de dominios de código.
Cuando la aplicación software protegida de dispositivo móvil recibe datos para almacenamiento en la al menos parte de la parte de la base de datos que no está asociada a personalización / asignación de seguridad de dominios de código, esos son cifrados usando las referidas otras una o más partes del parámetro de seguridad [psia-RS3 / psib-RPS32 ], antes de ser almacenados en la correspondiente al menos parte de la parte de la base de datos de la aplicación.
• Otras una o más partes del parámetro de seguridad [ps1a-RS3 / psib-RPS32 ] son asignadas como el parámetro de seguridad que es parte de la clave de ofuscación usada para ofuscar [ps2 b-RPS32], [ch2b-RPS32] y [ro2b-RPS32].
o [chi1a-RS3 , ch1 b-RPS32 ] se convierten en las dos partes de la misma red de checksums, que será usada para verificar la integridad de partes del código de la aplicación de las funciones DC3/1(f1 DC3 / 1 , f2 üC3 /i, ■ ■ ■) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC3/1(flDC3/i, f2 DC3 /i, ■■■).
• En estas implementaciones chib-RPS32 = chib-RPS3 i ;
• Conforme a algunas implementaciones alternativas chib-RPS3 2 = chib-RPS3 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la red de checksums [chia-RS3 / chib-RPS32 ] serán usadas para verificar la integridad de partes del código de la aplicación de las funciones D C 3/i(fiDC3/i, f2DC3/i, ■■■) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC3/i(fi DC3/i, f2DC3/i, ■■■);
o [roia-RS3 , roib-RPS32 ] se convierten en las dos partes de la misma regla de ofuscación, que es usada para ofuscar parte del código de la aplicación de las funciones D C 3/i(fiDC3/i, f2 DC3 /i, ■■■) junto con parte de los [psia-RS3, ps3-RS3, ps4-RS3..., psh-RS3] y parte de los [chia-RS3, ch3-RS3, cIv rs3..., chh-RS3] embebidos en el código de la aplicación de las funciones D C 3/i(fiDC3/i, f2DC3/i, ...).
• En estas implementaciones roib-RPS32 = roib-RPS3 i ;
• Conforme a algunas implementaciones alternativas roib-RPS3 2 = roib-RPS3 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [roia-RS3 / roib-RPS32 ] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la réplica de la función f¡DC3 /i en DC3/i que está asociada al valor dado del parámetro.
- Ofuscación de [ps2 b-RPS32 , ro2 b-RPS32 , ch2 b-RPS32 ] usando un algoritmo de ofuscación y la clave de ofuscación para proteger datos de personalización de seguridad DC3/2, como se ilustra en la figura 2.g (en este proceso de personalización de seguridad x = 3). En estas implementaciones:
o El parámetro de seguridad que es parte de la clave de ofuscación está constituido por al menos parte de [psia-RS3] y al menos parte de [psib-RPS32]. Los primeros i0 dígitos de IDDusuario2 son también parte de la clave de ofuscación;
o [ps2 a-RS3 , ps2 b-RPS32 ] se convierten en las dos partes del mismo parámetro de seguridad:
• Una o más partes de [ps2 a-RS3 , ps2 b-RPS32 ] serán usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC3/2 tras un pre registro previo con éxito del primer servicio), asociado al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con iDDusuario2 ) y ha sido lanzada desde DC3/2 con la personalización de seguridad adecuada;
• Otras una o más partes del parámetro de seguridad [ps2 a-RS3 / ps2 b-RPS32 ] serán usadas para proteger ciertos datos sensibles no estructurados antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 (ej. para proteger claves/datos sensibles necesarios para que la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 calcule credenciales dinámicas asociadas a servicios provistos por el proveedor de servicios i; ej. protección de claves de sesión), cuando psDCs-asignación es establecido al valor asociado a DC3/i y DC3/2.
• Otras una o más partes del parámetro de seguridad [ps2 a-RS3 / ps2 b-RPS32 ] serán usadas por la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 para ofuscar ciertos datos sensibles, en el contexto de la ejecución de algunas instrucciones de código DC3/2, para evitar que sean expuestas en claro en una o más memorias de trabajo del dispositivo móvil, cuando psDCs-asignación es establecido al valor asociado a DC3/1 y DC3/2.
o [chi2 a-RS3 , ch2 b-RPS32 ] se convierten en las dos partes de la misma red de checksums, que será usada para verificar la integridad de partes del código de la aplicación de las funciones DC3/2(f1 DC3 / 2 , f2 DC3 /2 , ■ ■ ) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de funciones CD3/2(f1cD3/2, f2 cD3/2 , ...).
• En estas implementaciones ch2 b-RPS32 = ch2 b-RPS3 i ;
• Conforme a algunas implementaciones alternativas ch2 b-RPS3 2 = ch2 b-RPS3 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la red de checksums [chi2 a-RS3 / ch2 b-RPS32 ] serán usadas para verificar la integridad de partes del código de la aplicación de las funciones DC3/2(flDC3/2, f2 DC3 /2 , ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC3/2(f1 DC3/2, f2DC3/2, ...);
o [ro2 a-RS3 , ro2 b-RPS32 ] se convierten en las dos partes de la misma regla de ofuscación, que son usadas para ofuscar parte del código de la aplicación de las funciones DC3/2(flDC3/2, f2 DC3 /2 , ...) junto con parte de los [ps2a-RS3, ps(h+i)-RS3, ps(h+2)-RS3. , psp-RS3] y parte de los [ch2a-RS3, ch(h+i)-RS3, ch(h+2 )-RS3 ..., chp-RS3] embebidos en el código de la aplicación de las funciones DC3/2(flDC3/2, f2DC3/2, ...).
• En estas implementaciones ro2 b-RPS32 = ro2 b-RPS3 i ;
• Conforme a algunas implementaciones alternativas ro2 b-RPS32 = ro2 b-RPS3 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro2a-RS3 / ro2b-RPS32] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la réplica de la función fiDC3 /2 en DC3/2 que está asociada al valor dado del parámetro.
Estas asignaciones y datos preparados son almacenados en la base de datos asociada a aplicaciones software de dispositivo móvil, en relación al dispositivo móvil del usuario 2, la aplicación software protegida de dispositivo móvil y el proceso de personalización de seguridad.
En el paso ( i i ) de la figura i al menos parte del registro de personalización de seguridad de ciclo de vida asignado, y la asociación al dispositivo móvil del usuario y a la aplicación software protegida de dispositivo móvil es enviada al proveedor de servicios correspondiente tal que pueda usar al menor parte de ello en el contexto de ciertos procesos de ciclo de vida de la aplicación software protegida de dispositivo móvil. Conforme a algunas implementaciones (en relación a la figura 2.g) al menos parte de las asignaciones y datos asociados al dispositivo móvil del usuario 2 y a la personalización de seguridad de la aplicación software protegida de dispositivo móvil son enviados al proveedor de servicios i para almacenamiento y/o para uso de al menos parte de ello en el contexto de ciertos procesos de ciclo de vida de la aplicación software protegida de dispositivo móvil asociada al dispositivo móvil del usuario 2. En un ejemplo particular:
• Las una o más partes de [psia-RS3 , psib-RPS32 ] que serán usadas para validar que una solicitud para pre registrar un primer servicio, asociado al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con IDDusuario2 ) y ha sido lanzada desde DC3/i con la personalización de seguridad adecuada y;
• Las una o más partes de [ps2 a-RS3 , ps2 b-RPS32 ] que serán usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC3/2 tras un pre registro previo con éxito del primer servicio), asociado al proveedor de servicios i, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con IDDusuario2 ) y ha sido lanzada desde DC3/2 con la personalización de seguridad adecuada; son enviadas al proveedor de servicios 1 para almacenamiento y para uso durante el proceso de pre registro y de registro, respectivamente, de un primer servicio en la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2.
En el paso (12) de la figura 1 datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida asignado son enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario. En particular, datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario son enviados a la aplicación software protegida de dispositivo móvil no personalizada en seguridad en el dispositivo móvil del usuario. Conforme a algunas implementaciones (en relación a la figura 2.g) [psib-RPS32 , roib-RPS32 , ch1 b-RPS32 ] son enviados en formato ofuscado a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2.
En el paso (13) de la figura 1 el dispositivo móvil del usuario recibe los datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones la habilitación de el al menos uno de los uno o más primeros dominios de código está asociada a uno o más parámetros de seguridad relativos al registro de personalización de seguridad de ciclo de vida (ej. ps1 b-RPS32 relativo al registro de personalización de seguridad de ciclo de vida RPS32), que son diferentes que los correspondientes del registro de personalización de seguridad (ej. psibrps21 , ps1b-RPS31, ps1b-RPS41, ■■■, psib-RPSii, ■■■. ps1 b-RPSn1 en relación a RPS-I).
Conforme a algunas implementaciones (en relación a la figura 2.g) el dispositivo móvil del usuario 2 recibe en formato ofuscado (la ofuscación usando un método que usa un parámetro de seguridad que está embebido en una función de DC1 y al menos parte de IDDusuario2 ) el valor de dato para almacenamiento en la parte de la aplicación software protegida de dispositivo móvil asociada a psoCs-asignación, dicho valor haciendo que la aplicación software protegida de dispositivo móvil use DC3/1, DC3/2 y DC1 durante su ejecución. En estas implementaciones el dispositivo móvil del usuario 2 también recibe [psib-RPS32 , roib-RPS32 , chib-RPS32 ] en formato ofuscado desde el proveedor de servicios de personalización y estos son almacenados en la parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a DC3/1 (como se ilustra en la figura 2.j). Los datos de personalización de seguridad [psib-RPS32 , roib-RPS32 , chib-RPS32 ] recibidos y almacenados habilitan el primer dominio de código DC3/1 para operación regular, la ofuscación de dichos datos siendo relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en el segundo dominio de código DC1 y que son requeridos para habilitar el primer dominio de código DC3/1 para operación regular, como se ha descrito en relación a la figura 2.d.
Ventajosamente, después de que la personalización de seguridad anterior haya sido realizada, el referido al menos uno de los uno o más primeros dominios de código pueden ser usados para realizar regularmente las funciones asociadas de ciclo de vida de la aplicación.
Durante su ciclo de vida la aplicación software protegida de dispositivo móvil será capaz de des ofuscar psocsasignacióny de determinar que DC3/1, DC3/2 y DC1 deben ser usados durante su ejecución. También, la aplicación software protegida de dispositivo móvil será capaz de des ofuscar [psib-RPS32 , roib-RPS32 , chib-RPS32 ] usando el algoritmo de ofuscación y la clave de ofuscación que protege datos de personalización de seguridad DC3/1, como ya se ha ilustrado en relación a la figura 2.g (x = 3). Más en detalle:
- Para solicitar el pre registro de un primer servicio, una o más partes de [psia-RS3 / spib-RPS32 ] son des ofuscadas por la aplicación software protegida de dispositivo móvil, y un cálculo basado en las una o más partes des ofuscadas de [psia-RS3 / psib-RPS32 ] es enviado al proveedor de servicios i para verificación de que la solicitud es enviada desde el dispositivo apropiado y ha sido lanzada desde el dominio de código adecuado (DC3/1) con la correcta personalización de seguridad. Como se ha referido anteriormente, el proveedor de servicios i ha almacenado previamente las una o más partes de [psia-RS3 / psib-RPS32 ] en relación al dispositivo móvil del usuario 2, para usarlas durante el proceso de verificación.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [psia-RS3 / psib-RPS32 ] son usadas para proteger al menos parte de la parte de la base de datos de la aplicación asociada a DC3/1 y DC3/2 (y no asociada a personalización / asignación de seguridad de dominios de código).
Cuando la aplicación software protegida de dispositivo móvil requiere del uso de datos almacenados en dicha al menos parte de la parte de la base de datos, las otras una o más partes del parámetro de seguridad [ps1a-RS3 / ps1b-RPS32] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar los datos en la base de datos, para uso.
- Otras una o más partes del parámetro de seguridad [ps1a-RS3 / psib-RPS32] serán des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para calcular la clave de ofuscación para des ofuscar [ps2b-RPS32], [ch2b-RPS32] y [ro2b-RPS32], cuando sea requerido.
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ch1a-RS3 , ch1b-RPS32 ] serán usados para verificar la integridad de las partes relativas del código de la aplicación de las funciones DC3/1(f1 dc3 /i , f2 üC3 /i, ■■■) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC3/1(flDC3/i, f2DC3/i, ■■■). Cuando la aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [chia-RS3 , chib-RPS32 ] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. Como se ha referido anteriormente, en estas implementaciones chib-RPS32 = chib-RPS3 i ;
• Conforme a las implementaciones alternativas referidas anteriormente, chib-RPS32 = chib-RPS3 i y un parámetro en psDCs-asignación ha sido establecido a un valor dado tal que una o más partes asociadas de la red de checksums [chia-RS3 / chib-RPS32 ] serán usadas para verificar la integridad de partes relativas del código de la aplicación de las funciones D C 3/i(fiDC3/i, f2DC3/i, ■■■) y de al menos partes relativas de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC3/i(fi DC3/i, f2DC3/i, ■■■);
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [roia-RS3 , roib-RPS32 ] será usada para des ofuscar la parte relativa del código de la aplicación de las funciones D C 3/i(fiDC3/i, f2DC3/i, ...), la parte relativa de los [psia-RS3 , ps3-RS3 , ps4 -RS3 ..., psn-RS3 ] y la parte relativa de los [chia-RS3 , ch3-RS3 , chi4 -RS3 ..., chh-RS3 ] embebidos en el código de la aplicación de funciones C D 3/i(fiCD3/i, f2CD3/i, ■■■). Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha parte referida del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos, el correspondiente proceso de des ofuscación es aplicado usando [roia-RS3 / roib-RPS32 ]. Como se ha referido anteriormente, en estas implementaciones roib-RPS32 = roib-RPS3 i ;
• Conforme a las implementaciones alternativas referidas anteriormente roib-RPS32 = roib-RPS3 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [roia-RS3 / roib-RPS32 ] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos de la réplica de la función fidc3/i en DC3/i que está asociada al valor dado del parámetro cuando la aplicación software protegida de dispositivo móvil requiere el uso de dicha parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos.
En referencia nuevamente a la figura i, conforme a algunas implementaciones diferentes grupos de uno o más primeros dominios de código no-habilitados son personalizados en términos de seguridad en diferentes instantes de tiempo. Esta aproximación incrementa la seguridad de la aplicación software protegida de dispositivo móvil.
En las implementaciones descritas en las figuras 2.a a 2.l, DCx/2 son otros primeros dominios de código. Los pasos (i4a) a (i4e) descritos a continuación son relativos a la aplicación software protegida de dispositivo móvil instalada en el dispositivo móvil del usuario 2, el registro de personalización de seguridad de ciclo de vida asignado es RPS32 y psDCs-asignación tiene un valor de dato asignado asociado a DC3/i y DC3/2, por lo que en este contexto DC3/2 es el otro primer dominio de código.
También, por simplicidad, en el contexto de las figuras 2.a a 2.l, los pasos (i5a) a (i5e) y los pasos (i6a) a (i6e) no tienen lugar.
Tal y como ya se ha descrito en la figura i, el paso (i4a) representa una solicitud sucesiva para una personalización de seguridad de al menos otro uno o más primeros dominios de código, enviada desde el dispositivo móvil del usuario al proveedor de servicios de personalización (en el contexto actual: una personalización de seguridad de DC3/2 enviada desde el dispositivo móvil del usuario 2).
En estas implementaciones, cada solicitud de dispositivo móvil de usuario es lanzada por uno o más dispositivos de procesamiento usando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular (en el contexto actual: eso es código ejecutable perteneciente a DC3/1, la solicitud lanzada desde el dispositivo móvil del usuario 2).
En el paso (14a) de la figura 1 una solicitud sucesiva es enviada desde el dispositivo móvil del usuario 2 al proveedor de servicios de personalización y en el paso (14b) el proveedor de servicios de personalización recibe la solicitud sucesiva desde el dispositivo móvil del usuario 2, y uno o más dispositivos de procesamiento del proveedor de servicios de personalización pueden obtener en el paso (14c) datos de personalización de seguridad ([ps2 b-RPS32 , ro2 b-RPS32 , ch2 b-RPS32 ]) desde el registro de personalización de seguridad de ciclo de vida previamente asignado al dispositivo móvil del usuario (desde RPS32). Conforme a algunas implementaciones los datos de personalización de seguridad han sido previamente obtenidos del registro de personalización de seguridad: esto puede ser realizado ej. en el paso (10), donde como se ha descrito anteriormente [ps2 b-RPS32 , ro2 b-RPS32 , ch2 b-RPS32 ] han sido almacenados en formato ofuscado en la base de datos asociada a aplicaciones software protegidas de dispositivo móvil, en relación al dispositivo móvil del usuario 2, la aplicación software protegida de dispositivo móvil y el proceso de personalización de seguridad.
En el paso (14d) de la figura 1 los datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida RPS32 previamente asignado al dispositivo móvil del usuario 2 son enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario 2. En particular, datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida (RPS32) son enviados a la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad. Conforme a algunas implementaciones (en relación a la figura 2.g) [ps2 b-RPS32 , ro2 b-RPS32 , ch2 b-RPS32 ] son enviados en formato ofuscado a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2.
En el paso (14e) de la figura 1 el dispositivo móvil del usuario 2 recibe desde el proveedor de servicios de personalización los datos de personalización de seguridad ([ps2 b-RPS32 , ro2 b-RPS32 , ch2 b-RPS32 ] en formato ofuscado) asociados al registro de personalización de seguridad de ciclo de vida (RPS32) relativo al dispositivo móvil del usuario 2 en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos son almacenados en la parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a DC3/2 (como se ilustra en la figura 2.j), los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código (DC3/2) que está asociado a la solicitud particular.
Conforme a algunas implementaciones, al menos uno del otro uno o más primeros dominios de código (DC3/2) está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código (DC3/1) a través de la personalización de seguridad ([ps2 b-RPS32 , ro2 b-RPS32 , ch2 b-RPS32 ]), dicha personalización relativa a parámetros de seguridad (al menos parte de [ps1a-RS3 , ps1b-RPS32 ]) y/o reglas de ofuscación (al menos parte de [ro1a-RS3 , ron>RPS32 ]) y/o datos de checksums de código (al menos parte de [ch1ars3 , ch1b-RPS32 ]) que están al menos parcialmente disponibles en los uno o más primeros dominios de código (DC3/1) y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
Conforme a algunas implementaciones, al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario y están disponibles en una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a uno o más primeros dominios de código que han sido previamente habilitados para operación regular ([ps1 b-RPS32 ]) y/o [ro1b-RPS32 ]) y/o [ch1b-RPS32 ] están disponibles en una parte de la base de datos de la aplicación que está asociada a DC3/1).
Ventajosamente, una vez que la personalización de seguridad anterior ha sido realizada, el referido al menos otro uno o más primeros dominios de código puede ser usado para realizar regularmente las funciones asociadas de ciclo de vida de la aplicación.
Durante su ciclo de vida la aplicación software protegida de dispositivo móvil será capaz de des ofuscar [ps2 brps32 , ro2 b-RPS32 , ch2 b-RPS32 ] usando el algoritmo de ofuscación y la clave de ofuscación que protege datos de personalización de seguridad DC3/2, como ya se ha ilustrado en relación a la figura 2.g (x = 3). Más en detalle:
- Para solicitar el registro del primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC3/2 tras un pre registro previo con éxito del primer servicio), una o más partes de [ps2 a-RS3 / ps2 b RPS32 ] son des ofuscadas por la aplicación software protegida de dispositivo móvil, y un cálculo basado en las des ofuscadas una o más partes de [ps2 a-RS3 / ps2 b-RPS32 ] es enviado al proveedor de servicios 1 para verificación de que la solicitud es enviada desde el dispositivo apropiado y ha sido lanzada desde el dominio de código adecuado (DC3/2) con la personalización de seguridad adecuada. Como se ha referido anteriormente, el proveedor de servicios 1 ha almacenado previamente las una o más partes de [ps2 a-RS3 / ps2 b-RPS32 ] en relación al dispositivo móvil del usuario 2, para usarlas durante el proceso de verificación.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [ps2 a-RS3 / ps2 b-RPS32 ] son usadas para proteger ciertos datos sensibles no estructurados antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2. Conforme a algunas implementaciones cuando la aplicación software protegida de dispositivo móvil requiere el uso de al menos parte de los datos sensibles no estructurados, las otras una o más partes del parámetro de seguridad [ps2 a-RS3 / ps2 b-RPS32 ] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar los al menos parte de los datos sensibles no estructurados almacenados, para uso.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [ps2 a-RS3 / ps2 b-RPS32 ] son usadas para ofuscar ciertos datos sensibles, en el contexto de la ejecución de algunas instrucciones de código DC3/2, para evitar que sean expuestos en claro en una o más memorias de trabajo del dispositivo móvil del usuario 2. Cuando, durante la ejecución de ciertas instrucciones de código DC3/2, uno o más dispositivos de procesamiento en el dispositivo móvil del usuario 2 requieren usar los datos sensibles ofuscados previamente almacenados en las una o más memorias de trabajo, estos utilizan las otras una o más partes de [ps2 a-RS3 / ps2 b-RPS32 ] (y la regla de ofuscación referida anteriormente en relación a la figura 2.b) para obtener los datos adecuados para el relativo cálculo/proceso.
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ch2 a-RS3 , ch2 b-RPS32 ] será usado para verificar la integridad de las partes relativas del código de la aplicación de las funciones DC3/2(f1 DC3 / 2 , f2üC3/2, ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC3/2(flDC3/2, f2DC3/2, ...). Cuando la aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [ch2 a-RS3 , ch2 b-RPS32 ] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. Como se ha referido anteriormente, en estas implementaciones ch2 b-RPS32 = ch2 b-RPS3 i ;
• Conforme a las implementaciones alternativas referidas anteriormente, ch2 b-RPS32 = ch2 b-RPS3 i y un parámetro en psDCs-asignación ha sido establecido a un valor dado tal que una o más partes asociadas de la red de checksums [ch2 a-RS3 / ch2 b-RPS32 ] serán usadas para verificar la integridad de partes relativas del código de la aplicación de las funciones DC3/2(flDC3/2, f2 DC3 /2 , ...) y de al menos partes relativas de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC3/2(f1 DC3/2, f2DC3/2, ...);
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ro2 a-RS3 , ro2 b-RPS32 ] será usada para des ofuscar la parte relativa del código de la aplicación de las funciones DC3/2(f1 DC3 / 2 , f2DC3/2, ...), la parte relativa de los [ps2 a-RS3 , ps(h+i)-RS3 , ps(h+2 )-RS3 ..., psp-RS3 ] y la parte relativa de los [ch2 a-RS3 , ch(h+i)-RS3, ch(h+2)-RS3..., chp-RS3] embebidos en el código de la aplicación de las funciones DC3/2(flDC3/2, f2DC3/2, ...). Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha referida parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas, el correspondiente proceso de des ofuscación es aplicado usando [ro2 a-RS3 / ro2 b-RPS32 ]. Como se ha referido anteriormente, en estas implementaciones ro2 b-RPS32 = ro2 b-RPS3 i ;
• Conforme a las implementaciones alternativas referidas anteriormente ro2 b-RPS32 = ro2 b-RPS3 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro2 a-RS3 / ro2 b-RPS32 ] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos de la réplica de la función fiDC3 /2 en DC3/2 que está asociada al valor dado del parámetro cuando la aplicación software protegida de dispositivo móvil requiere el uso de dicha parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas.
En un ejemplo particular los procesos incluyendo hasta el paso i3 ya han sido realizados tal que la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 está en un estado parcialmente personalizado de seguridad. Como se ha descrito anteriormente, en el paso (i4a) una solicitud sucesiva es enviada desde el dispositivo móvil del usuario 2 y recibida en el paso (i4b) por el proveedor de servicios de
5i
personalización. En este ejemplo, al inicio del paso (14c), uno o más dispositivos de procesamiento del proveedor de servicios de personalización verifican si la solicitud ha sido recibida (paso 14b) más tarde que un periodo predefinido de tiempo después de que datos de personalización de seguridad fueran enviados a la aplicación software protegida de dispositivo móvil en el paso (12).
Si la solicitud ha sido recibida más tarde que dicho periodo predefinido de tiempo, entonces la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad asociada al dispositivo móvil del usuario 2 expira en el sistema del proveedor de servicios de personalización. Conforme a algunas implementaciones, el proveedor de servicios de personalización notifica (no ilustrado en la figura 1) al proveedor de servicios 1 acerca del estado de expiración de la aplicación software protegida de dispositivo móvil asociada al dispositivo móvil del usuario 2. También, una notificación indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado es enviada al dispositivo móvil del usuario 2 y recibida en el dispositivo móvil del usuario 2.
Por tanto, conforme a algunas implementaciones uno o más dispositivos de procesamiento en el sistema del proveedor de servicios de personalización hacen una aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad expirar si una solicitud para una personalización de seguridad de al menos otro uno o más primeros dominios de código (ej. DC3/2) es recibida más tarde que un periodo de tiempo predefinido después de que datos de personalización de seguridad relativos a una solicitud previa para una personalización de seguridad de al menos uno (ej. DC3/1) u otro diferente uno de los uno o más primeros dominios de código fueran enviados a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada o parcialmente-personalizada. Esta aproximación incrementa adicionalmente la seguridad de la aplicación software protegida de dispositivo móvil.
También, conforme a algunas implementaciones, una notificación desde el proveedor de servicios de personalización indicando que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad ha expirado es enviada al dispositivo móvil del usuario 2 y recibida en el dispositivo móvil del usuario 2.
Conforme a algunas implementaciones:
- [ps1b-RPS32, ro1b-RPS32, ch1b-RPS32] en formato ofuscado son enviadas a (paso (12)) y almacenadas en (paso (13) la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2. Los datos de personalización de seguridad [ps1b-RPS32 , ro1b-RPS32 , ch1 b-RPS32 ] recibidos y almacenados habilitan el primer dominio de código CD3/1 para operación regular.
- Una o más partes de [ps1a-RS3 , ps1 b-RPS32 ] serán posteriormente usadas para validar que una solicitud para pre registrar un primer servicio, asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2, y ha sido lanzada desde DC3/1 con la personalización de seguridad adecuada. En un ejemplo particular el usuario 2 obtiene un código de activación y este es enviado en el contexto del proceso de pre registro del primer servicio, desde el dispositivo móvil del usuario 2 al proveedor de servicios de personalización, para validación. En un ejemplo particular los pasos (14a) a (14e) son también realizados en el contexto del proceso de pre registro del primer servicio (ej. tras una validación con éxito del código de activación referido en el ejemplo previo), por lo que [ps2b-RPS32, ro2b-RPS32, ch2b-RPS32] serán recibidos y almacenados en formato ofuscado en la parte de la base de datos de la aplicación asociada a DC3/2 antes de que el proceso de pre registro del primer servicio finalice.
- Una o más partes de [ps2 a-RS3 , ps2 b-RPS32 ] serán más tarde usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC3/2 tras un pre registro previo con éxito del primer servicio), asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 y ha sido lanzada desde DC3/2 con la personalización de seguridad adecuada.
En un ejemplo particular un PIN (Número de Identificación Personal) es seleccionado por el usuario 2 e insertado en el dispositivo móvil del usuario 2 durante el proceso de registrar dicho primer servicio en la aplicación software protegida de dispositivo móvil y datos enviados a y almacenados en la base de datos de la aplicación software protegida de dispositivo móvil durante el proceso de pre registro de dicho primer servicio son usados para autenticar el registro del PIN seleccionado en el sistema del proveedor de servicios 1 (ej. dichos datos pueden permitir calcular una credencial dinámica basada-en-PIN que puede ser autenticada por el proveedor de servicios de personalización, así asegurando que el cálculo ha sido realizado desde el dispositivo móvil del usuario 2 y ej. por funciones en DC3/2, con la personalización de seguridad adecuada aplicada).
Si las validaciones tienen éxito el proceso de registro puede concluir con éxito (ej. enviando datos asociados al proceso de registro del primer servicio al dispositivo móvil del usuario 2).
Conforme a algunas implementaciones, adicionalmente a establecer un límite de tiempo entre los pasos (12) y (14b) para que la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad expire, otro límite de tiempo asociado al total del proceso de pre registro y de registro del primer servicio en la aplicación software protegida de dispositivo móvil puede ser establecido, una vez que la aplicación software protegida de dispositivo móvil ya está en un estado de personalización parcial de seguridad. Ventajosamente, esos límites de tiempo pueden incrementar la seguridad del sistema.
En las implementaciones descritas en relación a la figura 2.g, el registro de personalización de seguridad de ciclo de vida asignado al dispositivo móvil del usuario 1 (RPS43) es diferente que el registro de personalización de seguridad de ciclo de vida asignado al dispositivo móvil del usuario 2 (RPS32); y estos son ambos diferentes que el registro de personalización de seguridad usado cuando se genera la aplicación software de dispositivo móvil personalizada en seguridad (RPS-I).
También, como se ha detallado extensamente en relación a la figura 2.g, conforme a algunas implementaciones los uno o más primeros/segundos dominios de código asociados en una o más memorias del proveedor de servicios de personalización a la aplicación software protegida de dispositivo móvil en un dispositivo móvil de un primer usuario (primeros dominios de código DC4/1 y DC4/2, asociados al dispositivo móvil del usuario 1) son diferentes que los uno o más primeros/segundos dominios de código asociados en una o más memorias del proveedor de servicios de personalización a la aplicación software protegida de dispositivo móvil en un dispositivo móvil de un segundo usuario (primeros dominios de código DC3/1 y DC3/2, asociados la dispositivo móvil del usuario 2).
Y, conforme a algunas implementaciones los uno o más primeros dominios de código habilitados a través de primeros datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un primer usuario (primeros dominios de código DC4/1 y DC4/2, asociados al dispositivo móvil del usuario 1) son diferentes que los uno o más primeros dominios de código habilitados a través de segundos datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un segundo usuario (primeros dominios de código CD3/1 y CD3/2, asociados al dispositivo móvil del usuario 2).
Como también se ha descrito anteriormente, conforme a algunas implementaciones los datos de personalización de seguridad recibidos en el dispositivo móvil de un primer usuario, los datos (ej. [ps1 b-RPS43 ], [ch1b-RPS43], [ro1b-RPS43] y [ps2b-RPS43], [ch2b-RPS43], [ro2b-RPS43] almacenados en la base de datos de la aplicación en formato ofuscado) habilitando en la aplicación uno o más primeros dominios de código (DC4/1 y DC4/2) para operación regular y asociados a un primer registro de personalización de seguridad de ciclo de vida (RPS43) que incluye primeros parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código ([ps1b-RPS43], [ch1b-RPS43], [ro1b-RPS43] y [ps2b-RPS43], [ch2b-RPS43], [ro2b-RPS43]), son diferentes que los datos de personalización de seguridad recibidos en el dispositivo móvil de un segundo usuario, los datos (ej. [psn>RPS32 ], [ch1b-RPS32], [ro1b-RPS32] y [ps2b-RPS32], [ch2b-RPS32], [ro2b-RPS32] almacenados en la base de datos de la aplicación en formato ofuscado) habilitando en la aplicación uno o más primeros dominios de código (DC3/1 y DC3/2) para operación regular y asociados a un segundo registro de personalización de seguridad de ciclo de vida (RPS32) que incluye segundos parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código ([ps1b-RPS32], [ch1b-RPS32], [ro1b-RPS32] y [ps2b-RPS32], [ctl2b-RPS32], [ro2b-RPS32]).
Ventajosamente, un atacante no es consciente de los dominios de código y datos de personalización de seguridad que serán asignados a / almacenados en la aplicación software protegida de dispositivo móvil de un usuario dado, para habilitar los primeros dominios de código asignados para operación regular, lo cual hace extremadamente difícil tener éxito en un posterior ataque. Este ataque es incluso más complicado si se establecen límites de tiempo para realizar ciertos procesos sensibles de habilitación, como se ha descrito anteriormente.
Además, gracias al proceso de asignación impredecible de dominios de código y los diferentes datos de personalización de seguridad aplicados a la aplicación software protegida de dispositivo móvil en diferentes dispositivos móviles de usuarios, para habilitar para operación regular los primeros dominios de código asignados, el incentivo para un ataque masivo disminuye drásticamente.
También, la asignación de dominios de código y los datos de personalización de seguridad pueden ser modificados durante el ciclo de vida de una aplicación software protegida de dispositivo móvil instalada en el dispositivo móvil de un usuario dado, lo cual aumenta aún más la seguridad del sistema.
Las figuras 2k y 2l son relativas a algunas implementaciones donde una aplicación software protegida de dispositivo móvil es re personalizada en términos de seguridad durante su ciclo de vida. En particular, se refieren a un proceso de re personalización de seguridad de la aplicación software protegida de dispositivo móvil instalada en el dispositivo móvil del usuario 2 (como se ha explicado anteriormente dicha aplicación ya está personalizada en términos de seguridad en relación al registro de personalización de seguridad de ciclo de vida RPS32).
Conforme a algunas implementaciones una re personalización de seguridad es iniciada (ej. en el paso (17) de la figura 1) por uno o más dispositivos de procesamiento en el sistema del proveedor de servicios de personalización (ej. un periodo de tiempo después de que se haya realizado una personalización / re personalización de seguridad previa; ej. debido a criterios de riesgo).
Conforme a otras implementaciones el proceso de re personalización de seguridad es iniciado como resultado de una conexión on-line establecida (no ilustrado en la figura 1) desde el dispositivo móvil del usuario 2 hacia el sistema del proveedor de servicios de personalización. En un ejemplo particular una credencial dinámica basada-en-PIN es recibida desde el dispositivo móvil del usuario 2 durante la conexión on-line, y verificación con éxito de dicha credencia es requerida para que uno o más dispositivos de procesamiento del sistema del proveedor de servicios de personalización inicien (ej. en el paso (17) de la figura 1) el proceso de re personalización de seguridad.
Como se ilustra en la figura 1, en el paso (17) uno o más dispositivos de procesamiento en el sistema del proveedor de servicios de personalización obtienen datos de re personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida (ej. en el caso de que RPS32 contenga datos asociados a uno o más procesos de re personalización de seguridad), o a otro registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario, desde la base de datos asociada a aplicaciones software protegidas de dispositivo móvil.
En las implementaciones descritas a continuación, la re personalización de seguridad de la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 será realizada en relación al registro de personalización de seguridad de ciclo de vida RPS2j, por lo que en el paso (17) de la figura 1 el nuevo registro de personalización de seguridad de ciclo de vida asignado por el módulo de personalización de seguridad al dispositivo móvil del usuario 2 es RPS2j, que está asociado a DC2/1, DC2/2 y DC1. Todavía en el paso (17), la asignación del nuevo registro de personalización de seguridad de ciclo de vida RPS2j al dispositivo móvil del usuario 2 es almacenada en la base de datos asociada a aplicaciones software de dispositivo móvil (datos relativos a RPS32, asignados actualmente a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2, son todavía válidos, dado que en esta fase el proceso de re personalización todavía no ha sido realizado).
En más detalle (tomando también como referencia las figuras 2k y 2l), conforme a algunas implementaciones el módulo de personalización de seguridad puede realizar las siguientes nuevas asignaciones y preparación de datos en el paso (17) de la figura 1, en relación al dispositivo móvil del usuario 2 y a la re personalización de seguridad:
- Asignación de RPS2j en el contexto del proceso de re personalización de seguridad en curso, asociado a DC2/1, DC2/2 y DC1 y a IDDusuario2 ;
- Asignar a psDCs-asignación un valor de dato asociado a DC2/1 y DC2/2 tal que, una vez personalizado en términos de seguridad, la aplicación software protegida de dispositivo móvil usará DC2/1, DC2/2 y DC1 durante su ejecución. En estas implementaciones el valor de dato es ofuscado usando un método que usa un parámetro de seguridad que está embebido en una función DC1 y al menos parte de IDDusUARIO2.
- Ofuscación de [ps1 b-RPS2j, ro1 b-RPS2 j, ch1b-RPS2j] usando un algoritmo de ofuscación y la clave de ofuscación para proteger datos de personalización de seguridad DC2/1, como se ilustra en la figura 2.k (en este proceso de personalización de seguridad x = 2). En estas implementaciones:
o los primeros 10 dígitos de IDDusuario2 son parte de la clave de ofuscación;
o [psia-RS2 , psib-RPS2j] se convierten en las dos partes del mismo parámetro de seguridad:
• Una o más partes de [psia-RS2 , psib-RPS2j] serán usadas para validar que una solicitud para pre registrar un primer servicio (si dicho pre registro está pendiente), asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con iDDusuario2) y ha sido lanzada desde DC2/1 con la personalización de seguridad adecuada;
• Otras una o más partes del parámetro de seguridad [ps1a-RS2 / ps1 b-RPS2 j] serán usadas para proteger datos en ciertas partes de la base de datos de la aplicación software protegida de dispositivo móvil (en este contexto, ciertas partes asociadas a DC2/1 y DC2/2). En estas implementaciones, dichas otras una o más partes del parámetro de seguridad son usadas para proteger al menos parte de la parte de la base de datos de la aplicación que no está asociada a personalización / asignación de seguridad de dominios de código.
Cuando la aplicación software protegida de dispositivo móvil recibe datos para almacenamiento en la al menos parte de la parte de la base de datos que no está asociada a personalización / asignación de seguridad de dominios de código, esos son cifrados usando las referidas otras una o más partes del parámetro de seguridad [ps1a-RS2 / ps1b-RPS2j], antes de ser almacenados en la correspondiente al menos parte de la parte de la base de datos de la aplicación.
• Otras una o más partes del parámetro de seguridad [ps1a-RS2 / psn>RPS2j] son asignadas como el parámetro de seguridad que es parte de la clave de ofuscación usada para ofuscar [ps2 b-RPS2j], [ctl2b-RPS2j] y [ro2b-RPS2j].
o [chi1a-RS2 , ch1 b-RPS2j] se convierten en las dos partes de la misma red de checksums, que será usada para verificar la integridad de partes del código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , f2 DC2 /1 , ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , f2 DC2 /1 , ■■■).
• En estas implementaciones ch1 b-RPS2j = ch1 b-RPS21 ;
• Conforme a algunas implementaciones alternativas ch1 b-RPS2j = ch1 b-RPS21 y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la red de checksums [chi1a-RS2 / ch1b-RPS2 j] serán usadas para verificar la integridad de partes del código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , f2 DC2 /1, ■■■) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2/1(f1 DC2/1, f2DC2/1, ■■■);
o [ro1a-RS2 , ro1b-RPS2j] se convierten en las dos partes de la misma regla de ofuscación, que es usada para ofuscar parte del código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , f2 DC2/1 , ■■■) junto con parte de los [ps1a-RS2 , ps3-RS2, ps4-RS2..., psg-RS2 ] y parte de los [ch1a-RS2 , ch3-RS2, ch4-RS2..., chg-RS2 ] embebidos en el código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , f2 DC2 /1 , ■■■).
• En estas implementaciones ron>RPS2j = ro1 b-RPS2 1
• Conforme a algunas implementaciones alternativas ron>RPS2j = ro1 b-RPS21 y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro1a-RS2 / ro1 b-RPS2 j] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la réplica de la función fiDC2 /1 en DC2/1 que está asociada al valor dado del parámetro.
- Ofuscación de [ps2 b-RPS2j, ro2 b-RPS2j, ch2 b-RPS2 j] usando un algoritmo de ofuscación y la clave de ofuscación para proteger datos de personalización de seguridad DC2/2, como se ilustra en la figura 2.k (en este proceso de personalización de seguridad x = 2). En estas implementaciones:
o El parámetro de seguridad que es parte de la clave de ofuscación está constituido por al menos parte de [ps1a-RS2 ] y al menos parte de [psn>RPS2j]. Los primeros 10 dígitos de IDDusuario2 son también parte de la clave de ofuscación;
o [ps2 a-RS2 , ps2 b-RPS2j] se convierten en las dos partes del mismo parámetro de seguridad:
• Una o más partes de [ps2 a-RS2 , ps2 b-RPS2j] serán usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC2/2 tras un pre registro previo con éxito del primer servicio, si dicho pre registro estaba pendiente), asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con IDDusuario2) y ha sido lanzada desde DC2/2 con la personalización de seguridad adecuada;
• Otras una o más partes del parámetro de seguridad [ps2 a-RS2 / ps2 b-RPS2j] serán usadas para proteger ciertos datos sensibles no estructurados antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 (ej. para proteger claves/datos sensibles necesarios para que la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 calcule credenciales dinámicas asociadas a servicios provistos por el proveedor de servicios 1; ej. protección de claves de sesión), cuando psDCs-asignación es establecido al valor asociado a DC2/1 y DC2/2.
• Otras una o más partes del parámetro de seguridad [ps2 a-RS2 / ps2 b-RPS2j] serán usadas por la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 para ofuscar ciertos datos sensibles, en el contexto de la ejecución de algunas instrucciones de código DC2/2, para evitar que sean expuestas en claro en una o más memorias de trabajo del dispositivo móvil, cuando psDCs-asignación es establecido al valor asociado a DC2/1 y DC2/2.
o [chi2 a-RS2 , ch2 b-RPS2j] se convierten en las dos partes de la misma red de checksums, que será usada para verificar la integridad de partes del código de la aplicación de las funciones DC2 /2 ( f lDC2 / 2 , f2 DC2 /2 , ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2 /2 ( f lDC2 / 2 , f2 DC2 /2 , ...).
• En estas implementaciones ch2b-RPS2j = ch2b-RPS2i;
• Conforme a algunas implementaciones alternativas ch2 b-RPS2j = ch2 b-RPS2 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la red de checksums [chi2 a-RS2 / ch2 b-RPS2 j] serán usadas para verificar la integridad de partes del código de la aplicación de las funciones DC2 /2 ( f lDC2 / 2 , f2 DC2 /2 , ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2/2(f1 DC2/2, f2DC2/2, ...);
o [ro2 a-RS2 , ro2 b-RPS2j] se convierten en las dos partes de la misma regla de ofuscación, que son usadas para ofuscar parte del código de la aplicación de las funciones DC2 /2 ( f lDC2 / 2 , f2 DC2 /2 , ...) junto con parte de los [ps2 a-RS2 , pste+i>RS2 , ps(g+2 )-RS2 . , psm-RS2 ] y parte de los [ch2 a-RS2 , ch(g+i)-RS2 , ch(g+2 )-RS2 ..., chm-RS2 ] embebidos en el código de la aplicación de las funciones DC2 /2 ( f lDC2 / 2 , f2DC2/2, ...).
• En estas implementaciones ro2 b-RPS2j = ro2 b-RPS2 i ;
• Conforme a algunas implementaciones alternativas ro2 b-RPS2j = ro2 b-RPS2 i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro2 a-RS2 / ro2 b-RPS2 j] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas de la réplica de la función fiDC2 /2 en DC2/2 que está asociada al valor dado del parámetro.
Estas asignaciones y datos preparados son almacenados en la base de datos asociada a aplicaciones software protegidas de dispositivo móvil, en relación al dispositivo móvil del usuario 2, la aplicación software protegida de dispositivo móvil y el proceso de re personalización de seguridad.
En el paso (i8 ) de la figura i datos de re personalización de seguridad asociados al nuevo registro de personalización de seguridad de ciclo de vida asignado (RPS2j) son enviados desde el proveedor de servicios de personalización a la aplicación software protegida de dispositivo móvil (en el dispositivo móvil del usuario 2) estando en un estado de seguridad parcialmente personalizada o personalizada, los datos de re personalización de seguridad son al menos parcialmente diferentes que los datos de personalización de seguridad. Conforme a algunas implementaciones (en relación a las figuras 2.k y 2.l) [psib-RPS2 j, roib-RPS2j, chib-RPS2 j] y [ps2 b-RPS2j, ro2 b RPS2 j, ch2 b-RPS2j] son enviados en formato ofuscado a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2.
En el paso (19) de la figura 1 el dispositivo móvil del usuario 2 recibe los datos de re personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida, o a otro registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario, en la aplicación software protegida de dispositivo móvil estando en un estado de seguridad parcialmente personalizada o personalizada, los datos de re personalización de seguridad son al menos parcialmente diferentes que los datos de personalización de seguridad y habilitan en la aplicación para operación regular al menos uno de los uno o más primeros dominios de código y/o al menos uno del otro uno o más primeros dominios de código. Ventajosamente, en esta invención al menos parte de la protección de seguridad puede ser renovada de vez en cuando o bajo ciertas circunstancias.
Conforme a algunas implementaciones (en relación a la figura 2.l) el dispositivo móvil del usuario 2 recibe en formato ofuscado (la ofuscación usando un método que usa un parámetro de seguridad que está embebido en una función de DC1 y al menos parte de IDDusuario2 ) desde el proveedor de servicios de personalización el valor de dato para almacenamiento en la parte de la aplicación software protegida de dispositivo móvil asociada a psDCs-asignación, dicho valor haciendo que la aplicación software protegida de dispositivo móvil use DC2/1, DC2/2 y DC1 durante su ejecución (y que por tanto deje de usar DC3/1 y CD3/2 durante su ejecución).
En estas implementaciones el dispositivo móvil del usuario 2 también recibe [ps1 b-RPS2 j, ron>RPS2j, ch1 b-RPS2j] y [ps2 b-RPS2 j, ro2 b-RPS2j, ch2 b-RPS2 j] en formato ofuscado desde el proveedor de servicios de personalización y estos son respectivamente almacenados en la parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a DC2/1 y DC 2/2 (como se ilustra en la figura 2.l).
Los datos de personalización de seguridad [ps1b-RPS2j, ro1b-RPS2 j, ch1 b-RPS2j] recibidos y almacenados habilitan el primer dominio de código DC2/1 para operación regular, la ofuscación de los datos [ps1 b-RPS2 j, ron>RPS2j, ch1 b-RPS2 j] siendo relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en el segundo dominio de código DC1 y que son requeridos para habilitar el primer dominio de código DC2/1 para operación regular, como se ha ilustrado parcialmente antes en relación a la figura 2.k (x = 2).
Los datos de personalización de seguridad [ps2 b-RPS2j, ro2 b-RPS2 j, ch2 b-RPS2j] recibidos y almacenados habilitan el otro primer dominio de código DC2/2 para operación regular, la ofuscación de los datos [ps2 b-RPS2j, ro2 b-RPS2j, ch2 b-RPS2 j] siendo relativa al parámetro de seguridad (otras una o más partes de [ps1a-RS2 / ps1 b-RPS2j]) que es parte de la clave de ofuscación que protege datos de re personalización de seguridad DC2/2, como se ha ilustrado anteriormente en relación a la figura 2.k (x = 2).
En el contexto descrito en las figuras 2.k y 2.l, DC2/2 es el al menos uno del otro uno o más primeros dominios de código. En relación a la re personalización de seguridad asociada al registro de personalización de seguridad de ciclo de vida RPS2j y al dispositivo móvil del usuario 2, el al menos uno del otro uno o más primeros dominios de código (DC2/2) está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código (DC2/1) a través de la re personalización de seguridad ([ps2 b-RPS2 j, ro2 b-RPS2 j, ch2 b-RPS2j] en formato ofuscado), dicha re personalización relativa a parámetros de seguridad (al menos parte de [ps1a-RS2 , psn>RPS2j]) y/o reglas de ofuscación (al menos parte de [ro1a-RS2 , ron>RPS2j]) y/o datos de checksums de código (al menos parte de [ch1a-RS2 , ch1b-RPS2 j]) que están al menos parcialmente disponibles en los uno o más primeros dominios de código (DC2/1) y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
También en el contexto de la re personalización de seguridad asociada al registro de personalización de seguridad de ciclo de vida RPS2j y al dispositivo móvil del usuario 2, al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados a una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a los uno o más primeros dominios de código ([psn>RPS2j]) y/o [ro1 b-RPS2j]) y/o [ch1b-RPS2j] están disponibles en una parte de la base de datos de la aplicación que está asociada a DC2/1).
También, en el proceso de re personalización de seguridad, en relación al dispositivo móvil del usuario 2, conforme a algunas implementaciones:
- La parte de la base de datos de la aplicación software protegida de dispositivo móvil asociada a datos de personalización de seguridad DC3/1 y DC3/2 es establecida a valores por defecto [psib-RPS3 VD, roib-RPS3 VD, chib-RPS3Vü] y [ps2b-RPS3VD, ro2b-RPS3VD, ch2b-RPS3VD], como se ilustra en la figura 2.l.
- Datos en ciertas partes de la base de datos de la aplicación software protegida de dispositivo móvil, previamente protegidos por las otras unas o más partes del parámetro de seguridad [ps1a-RS3 / ps1b-RPS32 ] (relativos a la “antigua” personalización de seguridad asociada a DC3/1 y DC3/2) son borrados y dichos datos son al menos parcialmente reemplazados durante el proceso de re personalización (tanto como sea posible / necesario) con datos de renovación enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario 2. Como ya se ha dicho anteriormente cuando esos datos de renovación son recibidos, otras una o más partes de [ps1a-RS2 / ps1 b-RPS2 j] serán usadas para proteger los datos de renovación en dichas ciertas partes de la base de datos de la aplicación software protegida de dispositivo móvil (en este contexto de re personalización, ciertas partes asociadas a DC2/1 y DC2/2).
En estas implementaciones, dichas otras una o más partes de [ps1a-RS2 / ps1b-RPS2 j] son usadas para proteger al menos parte de la parte de la base de datos de la aplicación que no está asociada a personalización / asignación de seguridad de dominios de código. En relación a la re personalización de seguridad, cuando la aplicación software protegida de dispositivo móvil recibe datos (del proveedor de servicios de personalización o de otras fuentes) para almacenamiento en la al menos parte de la parte de la base de datos que no está asociada a personalización / asignación de seguridad de dominios de código, esos son cifrados usando las referidas otras una o más partes del parámetro de seguridad [ps1a-RS2 / ps1b-RPS2j], antes de ser almacenados en la correspondiente al menos parte de la parte de la base de datos de la aplicación.
- Ciertos datos sensibles no estructurados almacenados en la base de datos de la aplicación software protegida de dispositivo móvil, protegidos previamente por las otras una o más partes del parámetro de seguridad [ps2 a-RS3 / p2 b-RPS32 ] (relativos a la “antigua” personalización de seguridad asociada a DC3/1 y DC3/2) son borrados y dichos datos son reemplazados durante el proceso de re personalización (tanto como sea posible / necesario) por ciertos datos sensibles no estructurados de renovación enviados desde el proveedor de servicios de personalización al dispositivo móvil del usuario 2.
En relación a la re personalización de seguridad, otras una o más partes del parámetro de seguridad [ps2 ars2 / ps2 b-RPS2j] serán usados para proteger dichos datos sensibles no estructurados de renovación antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 (ej. para proteger claves/ datos sensibles necesarios para que la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2 calcule credenciales dinámicas asociadas a servicios provistos por el proveedor de servicios 1; ej. protección de claves de sesión) , cuando psDCs-asignación es establecido al valor asociado a DC2/1 y DC2/2.
Ventajosamente, después de que la re personalización de seguridad anterior haya sido realizada, el referido al menos uno de los uno o más primeros dominios de código (DC2/1) y el al menos uno del otro uno o más primeros dominios de código (DC2/2) pueden ser usados para realizar regularmente las funciones asociadas de ciclo de vida de la aplicación.
Una vez que el proceso de re personalización de seguridad ha finalizado con éxito, en un paso posterior (no ilustrado en la figura 1) los datos enviados al proveedor de servicios 1 en el contexto del paso (11) de la figura 1 son actualizados. Conforme a algunas implementaciones al menos parte de las asignaciones y/o datos asociados al dispositivo móvil del usuario 2 y a la re personalización de seguridad de la aplicación software protegida de dispositivo móvil son enviados al proveedor de servicios 1 para almacenamiento y para uso de al menos parte de ellos en el contexto de ciertos procesos de ciclo de vida de la aplicación software protegida de dispositivo móvil asociada al dispositivo móvil del usuario 2. En un ejemplo particular:
• La una o más partes de [ps1a-RS2 , ps1b-RPS2 j] que serán usadas para validar que una solicitud para pre registrar un primer servicio (si dicho pre registro están pendiente), asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con IDDusuario2 ) y ha sido lanzada desde DC2/1 con la personalización de seguridad adecuada y;
• Las una o más partes de [ps2a-RS2, ps2b-RPS2j] que serán usadas para validar que una solicitud para registrar el primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC2/2 tras un pre registro previo con éxito del primer servicio, si dicho pre registro estaba pendiente), asociado al proveedor de servicios 1, en la aplicación software protegida de dispositivo móvil es recibida desde el dispositivo móvil del usuario 2 (con IDDusuario2) y ha sido lanzada desde DC2/2 con la personalización de seguridad adecuada;
son enviadas al proveedor de servicios 1 para almacenamiento y para uso durante el proceso de pre registro y de registro, respectivamente, de un primer servicio (si pendiente) en la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2.
Durante su ciclo de vida la aplicación software protegida de dispositivo móvil re personalizada en seguridad será capaz de des ofuscar psDCs-asignación y de determinar que DC2/1, DC2/2 y DC1 deben ser usados durante su ejecución. También, la aplicación software protegida de dispositivo móvil será capaz de des ofuscar [psn>RPS2j, ro1b-RPS2j, ch-ib-RPS2j] usando el algoritmo de ofuscación y la clave de ofuscación que protege datos de personalización de seguridad DC2/1, como ya se ha ilustrado en relación a la figura 2.k (x = 2). Más en detalle:
- Para solicitar el pre registro de un primer servicio (si pendiente), una o más partes de [ps1a-RS2 / psn>RPS2j] son des ofuscadas por la aplicación software protegida de dispositivo móvil, y un cálculo basado en las una o más partes des ofuscadas de [ps1a-RS2 / psn>RPS2j] es enviado al proveedor de servicios 1 para verificación de que la solicitud es enviada desde el dispositivo apropiado y ha sido lanzada desde el dominio de código adecuado (DC2/1) con la correcta personalización de seguridad. Como se ha referido anteriormente, el proveedor de servicios 1 ha almacenado previamente las una o más partes de [ps1a-RS2 / ps1b-RPS2j] en relación al dispositivo móvil del usuario 2, para usarlas durante el proceso de verificación.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [ps1a-RS2 / ps1b-RPS2j] son usadas para proteger al menos parte de la parte de la base de datos de la aplicación asociada a d C2/1 y DC2/2 (y no asociada a personalización / asignación de seguridad de dominios de código). Cuando la aplicación software protegida de dispositivo móvil requiere del uso de datos almacenados en dicha al menos parte de la parte de la base de datos, las otras una o más partes del parámetro de seguridad [ps1a-RS2 / ps1b-RPS2j] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar los datos en la base de datos, para uso.
- Otras una o más partes del parámetro de seguridad [ps1a-RS2 / ps1b-RPS2j] serán des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para calcular la clave de ofuscación para des ofuscar [ps2b-RPS2j], [ch2b-RPS2j] y [ro2b-RPS2j], cuando sea requerido.
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ch1a-RS2 , ch1b-RPS2 j] serán usados para verificar la integridad de las partes relativas del código de la aplicación de las funciones DC2/1(f1 DC2 / 1 , f2 DC2 /1 , ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2/1(f1DC2/1, f2DC2/1, ■■■). Cuando la aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [ch1a-RS2 , ch1b-RPS2 j] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. Como se ha referido anteriormente, en estas implementaciones ch1b-RPS2 j = ch1b-RPS21 ;
• Conforme a las implementaciones alternativas referidas anteriormente, ch1b-RPS2 j = ch1 b-RPS21 y un parámetro en psDCs-asignación ha sido establecido a un valor dado tal que una o más partes asociadas de la red de checksums [ch1a-RS2 / ch1b-RPS2 j] serán usadas para verificar la integridad de partes relativas del código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , í2 dc2/1, ...) y de al menos partes relativas de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2/1(f1 DC2/1, f2DC2/1, ■■■);
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ro1a-RS2 , ron>RPS2j] será usada para des ofuscar la parte relativa del código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , Í2 dc2/1, ...), la parte relativa de los [ps1a-RS2 , ps3-RS2, ps4-RS2..., psg-RS2 ] y la parte relativa de los [ch1a-RS2 , ch3-RS2, chi4 -RS2 ..., chg-RS2 ] embebidos en el código de la aplicación de las funciones DC2 / 1 (f1 DC2 / 1 , f2 DC2 /1, ■■■). Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha parte referida del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos, el correspondiente proceso de des ofuscación es aplicado usando [ro1a-RS2 / ro1 b-RPS2 j]. Como se ha referido anteriormente, en estas implementaciones ro1b-RPS2j = ro1b-RPS21;
• Conforme a las implementaciones alternativas referidas anteriormente ro1 b-RPS2j = ron>RPS21 y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro1a-RS2 / ro1 b-RPS2 j] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos de la réplica de la función f¡DC2 /i en DC2/1 que está asociada al valor dado del parámetro cuando la aplicación software protegida de dispositivo móvil requiere el uso de dicha parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos.
También, durante su ciclo de vida la aplicación software protegida de dispositivo móvil re personalizada en seguridad será capaz de des ofuscar [ps2 b-RPS2j, ro2 b-RPS2j, ch2 b-RPS2 j] usando el algoritmo de ofuscación y la clave de ofuscación que protege datos de personalización de seguridad DC2/2, como ya se ha ilustrado en relación a la figura 2k (x = 2). Más en detalle:
- Para solicitar el registro del primer servicio referido anteriormente (la solicitud de registro siendo lanzada desde DC2/2 tras un pre registro previo con éxito del primer servicio, si dicho pre registro estaba pendiente), una o más partes de [ps2 a-RS2 / ps2 b-RPS2 j] son des ofuscadas por la aplicación software protegida de dispositivo móvil, y un cálculo basado en las des ofuscadas una o más partes de [ps2 a-RS2 / ps2 b-RPS2 j] es enviado al proveedor de servicios 1 para verificación de que la solicitud es enviada desde el dispositivo apropiado y ha sido lanzada desde el dominio de código adecuado (DC2/2) con la personalización de seguridad adecuada. Como se ha referido anteriormente, el proveedor de servicios 1 ha almacenado previamente las una o más partes de [ps2 a-RS2 / ps2 b-RPS2j] en relación al dispositivo móvil del usuario 2, para usarlas durante el proceso de verificación.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [ps2 a-RS2 / ps2 b-RPS2 j] son usadas para proteger ciertos datos sensibles no estructurados antes de ser enviados para almacenamiento a la aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario 2. Conforme a algunas implementaciones cuando la aplicación software protegida de dispositivo móvil requiere el uso de al menos parte de los datos sensibles no estructurados, las otras una o más partes del parámetro de seguridad [ps2 a-RS2 / ps2 b-RPS2j] son des ofuscadas por la aplicación software protegida de dispositivo móvil para usarlas para descifrar los al menos parte de los datos sensibles no estructurados almacenados, para uso.
- Como se ha detallado anteriormente, otras una o más partes del parámetro de seguridad [ps2 a-RS2 / ps2 b-RPS2j] son usadas para ofuscar ciertos datos sensibles, en el contexto de la ejecución de algunas instrucciones de código DC2/2, para evitar que sean expuestos en claro en una o más memorias de trabajo del dispositivo móvil del usuario 2. Cuando, durante la ejecución de ciertas instrucciones de código DC2/2, uno o más dispositivos de procesamiento en el dispositivo móvil del usuario 2 requieren usar los datos sensibles ofuscados previamente almacenados en las una o más memorias de trabajo, estos utilizan las otras una o más partes de [ps2 a-RS2 / ps2 b-RPS2j] (y la regla de ofuscación referida anteriormente en relación a la figura 2.b) para obtener los datos adecuados para el relativo cálculo/proceso.
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ch2 a-RS2 , ch2 b-RPS2j] será usado para verificar la integridad de las partes relativas del código de la aplicación de las funciones DC2/2(f1 DC2 / 2 , f2 DC2 /2 , ...) y de al menos partes de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2/2(flDC2/2, f2DC2/2, ...). Cuando la aplicación software protegida de dispositivo móvil requiere verificar la referida integridad, la red de checksums [ch2 a-RS2 , ch2 b-RPS2 j] es des ofuscada por la aplicación software protegida de dispositivo móvil para usarla en el proceso de verificación. Como se ha referido anteriormente, en estas implementaciones ch2 b-RPS2j = ch2 b-RPS2 i ;
• Conforme a las implementaciones alternativas referidas anteriormente, ch2 b-RPS2 j = ch2 b-RPS2 i y un parámetro en psDCs-asignación ha sido establecido a un valor dado tal que una o más partes asociadas de la red de checksums [ch2 a-RS2 / ch2 b-RPS2 j] serán usadas para verificar la integridad de partes relativas del código de la aplicación de las funciones DC2 /2 ( f lDC2 / 2 , f2 DC2 /2 , ...) y de al menos partes relativas de uno o más parámetros de seguridad embebidos en el código de la aplicación de las funciones DC2/2(f1 DC2/2, f2DC2/2, ...);
- Durante el ciclo de vida de la aplicación software protegida de dispositivo móvil, [ro2a-RS2, ro2b-RPS2j] será usada para des ofuscar la parte relativa del código de la aplicación de las funciones DC2/2(f1 DC2/2, f2DC2/2, ...), la parte relativa de los [ps2a-RS2 , pste+1>RS2, ps(g+2)-RS2 ..., psm-RS2] y la parte relativa de los [ch2a-RS2, ch(g+1)-RS2, ch(g+2)-RS2 ..., chm-RS2] embebidos en el código de la aplicación de las funciones DC2 /2 (f1 DC2/2 , f2DC2/2, ...). Cuando la aplicación software protegida de dispositivo móvil requiere usar dicha referida parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas, el correspondiente proceso de des ofuscación es aplicado usando [ro2a-RS2 / ro2b-RPS2j]. Como se ha referido anteriormente, en estas implementaciones ro2b-RPS2j = ro2b-RPS21
• Conforme a las implementaciones alternativas referidas anteriormente ro2b-RPS2j = ro2b-RPS2i y un parámetro en psDCs-asignación es establecido a un valor dado tal que una o más partes de la regla de ofuscación [ro2a-RS2 / ro2b-RPS2j] (esas partes asociadas al valor dado del parámetro) serán usadas para des ofuscar por la aplicación software protegida de dispositivo móvil una parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidos de la réplica de la función fiDC2/2 en DC2/2 que está asociada al valor dado del parámetro cuando la aplicación software protegida de dispositivo móvil requiere el uso de dicha parte del código de la aplicación / parámetros de seguridad embebidos / redes de checksums embebidas.
Esta invención provee un gran número de métodos y técnicas asociadas a uno o más proveedores de servicios y un proveedor de servicios de personalización en relación a la personalización de seguridad de una aplicación software de dispositivo móvil en un dispositivo móvil de un usuario.
Aunque se han descrito en detalle implementaciones de ejemplo para el propósito ilustrativo, se entiende que dicho detalle es solo para ese propósito, y que se pueden realizar variaciones en las mismas por aquellos expertos en la técnica sin apartarse del ámbito de la invención.
En una implementación particular la aplicación software protegida de dispositivo móvil es relativa a varios proveedores de servicios y una arquitectura equivalente a la ilustrada en la figura 2.b es replicada en el código de aplicación para cada uno de los proveedores de servicios.
Por tanto, ventajosamente cada proveedor de servicios puede tener sus propios primeros y segundos dominios de código asociados en la aplicación software protegida de dispositivo móvil, la parte asociada en la base de datos de la aplicación, registros de personalización de seguridad asociados, y personalización de seguridad aplicada en dispositivos móviles de los usuarios; conforme a algunas implementaciones (como se ilustra en la figura 3) el código de aplicación asociado a un proveedor de servicios dado en la aplicación software protegida de dispositivo móvil puede estar completamente aislado del código de aplicación asociado a otro proveedor de servicios dado.
La implementación ilustrada en la figura 3 se refiere a cuatro proveedores de servicios, cada uno con su propio registro de personalización de seguridad de inicialización (r Ps -Ips1 , RPS-Ips2 , RPS-Ips3 , RPS-Ips4 ). El registro de personalización de seguridad de inicialización de la aplicación incluye RPS-Ips1 , RPS-Ips2 , RPS-Ips3 y RPS-Ips4 y la protección de seguridad aplicada a la aplicación puede ser testada primero usando RPS-Ips1 (como se describe ej. en relación a la figura 2.b) para testar la parte de la aplicación asociada al proveedor de servicios 1; segundo usando RPS-Ips2 , para testar la parte de la aplicación asociada al proveedor de servicios 2; tercero usando RPS-Ips3 , para testar la parte de la aplicación asociada al proveedor de servicios 3; y finalmente usando r p s -i ps4 , para testar la parte de la aplicación asociada al proveedor de servicios 4;
Los pasos 8 a 19 descritos en la figura 1 pueden ser independientemente realizados en relación a los primeros y segundos dominios de código asociados a cada uno de los proveedores de servicios. La figura 3 muestra un ejemplo donde RPS2 jps1 ha sido usado para personalizar en términos de seguridad la parte de la base de datos de la aplicación software protegida de dispositivo móvil asociada a DC2/1ps1 y DC2/2ps1; la figura 3 también muestra un ejemplo donde RPSn3ps4 ha sido usado para personalizar en términos de seguridad la parte de la base de datos de la aplicación software protegida de dispositivo móvil asociada a DCn/1 ps4 y DCn/2 ps4.
Ventajosamente, conforme a algunas implementaciones uno o más primeros dominios de código asociados a un primer proveedor de servicios (ej. proveedor de servicios 1) pueden ser habilitados para operación regular por el proveedor de servicios de personalización independientemente de la habilitación para operación regular de otros uno o más primeros dominios de código asociados a un segundo proveedor de servicios (ej. proveedor de servicios 4).
Más allá, aunque las implementaciones reveladas en este documento con referencia a los dibujos comprenden aparatos y procesos informáticos realizados en aparatos informáticos, la invención también se extiende a programas informáticos, particularmente programas informáticos sobre o en un soporte, adaptados para poner la invención en práctica. El programa puede estar en forma de código fuente, código objeto, una fuente intermedia de código y código objeto tal como en forma parcialmente compilada, o en cualquier otra forma adecuada para su uso en la implementación de los procesos de acuerdo con la invención. El soporte puede ser cualquier entidad o dispositivo capaz de llevar el programa. Por ejemplo, el soporte puede comprender un medio de almacenamiento, como una Ro m , por ejemplo, un CD ROM o una ROM semiconductora, o un medio de grabación magnético, por ejemplo, un disquete o un disco duro. Además, el soporte puede ser un portador transmisible tal como una señal eléctrica u óptica que puede ser transportada mediante cable eléctrico u óptico o por radio u otros medios. Cuando el programa se materializa en una señal que puede ser transmitida directamente por un cable u otro dispositivo o medio, el soporte puede estar constituido por dicho cable u otro dispositivo o medio. Alternativamente, el soporte puede ser un circuito integrado en el que está incrustado el programa, estando adaptado el circuito integrado para realizar, o para uso en la ejecución de, los procesos relevantes.

Claims (1)

  1. REIVINDICACIONES
    1. Un método asociado con uno o más proveedores de servicios y un proveedor de servicios de personalización en relación a la personalización de seguridad de una aplicación software de dispositivo móvil en un dispositivo móvil de un usuario, el método incluyendo:
    usando por el proveedor de servicios de personalización una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad que están almacenados en una o más memorias para generar usando uno o más dispositivos de procesamiento una aplicación software protegida de dispositivo móvil que es personalizada en términos de seguridad usando datos del registro de personalización de seguridad, la aplicación generada incluyendo varios dominios de código, relativos a los uno o más proveedores de servicios, donde uno o más primeros dominios de código son vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar los uno o más primeros dominios de código para operación regular;
    enviando la aplicación software protegida de dispositivo móvil en un estado de seguridad nopersonalizada desde el proveedor de servicios de personalización a un servidor de distribución, dicho estado deshabilitando los uno o más primeros dominios de código para operación regular, y la aplicación software protegida de dispositivo móvil siendo almacenada en una o más memorias del servidor de distribución;
    recibiendo desde el dispositivo móvil del usuario una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada;
    enviando datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario, a la aplicación software protegida de dispositivo móvil no personalizada en seguridad en el dispositivo móvil del usuario, los datos de personalización de seguridad habilitando en la aplicación al menos uno de los uno o más primeros dominios de código para operación regular.
    2. Un método conforme a la reivindicación 1, en donde el proveedor de servicios de personalización es uno de los uno o más proveedores de servicios.
    3. Un método conforme a las reivindicaciones 1 o 2, en donde el habilitado de el al menos uno de los uno o más primeros dominios de código está asociado a uno o más parámetros de seguridad relativos al registro de personalización de seguridad de ciclo de vida, que son diferentes que los correspondientes del registro de personalización de seguridad.
    4. Un método conforme a cualquiera de las reivindicaciones 1 a 3, en donde la personalización de seguridad asociada al registro de personalización de seguridad de ciclo de vida es relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
    5. Un método conforme a cualquiera de las reivindicaciones 1 a 4, en donde solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código son recibidas desde el dispositivo móvil del usuario, cada solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida son enviados a la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
    6. Un método conforme a la reivindicación 5, en donde al menos uno del otro uno o más primeros dominios de código está vinculado en términos de seguridad por el proveedor de servicios de personalización a uno o más primeros dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
    7. Un método conforme a la reivindicación 6, en donde al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular han sido previamente enviados a una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a los uno o más primeros dominios de código.
    8. Un método conforme a cualquiera de las reivindicaciones 5 a 7, en donde uno o más dispositivos de procesamiento hacen una aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad expirar si una solicitud para una personalización de seguridad de al menos otro uno o más primeros dominios de código es recibida más tarde que un periodo de tiempo predefinido después de que datos de personalización de seguridad relativos a una solicitud previa para una personalización de seguridad de al menos uno u otro diferente uno de los uno o más primeros dominios de código fueran enviados a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada o parcialmentepersonalizada.
    9. Un método conforme a cualquiera de las reivindicaciones 1 a 8, en donde datos de re personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida, o a otro registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario, son enviados a la aplicación software protegida de dispositivo móvil estando en un estado de seguridad parcialmentepersonalizada o personalizada, los datos de re personalización de seguridad son al menos parcialmente diferentes que los datos de personalización de seguridad y habilitan en la aplicación para operación regular al menos uno de los uno o más primeros dominios de código y/o al menos uno del otro uno o más primeros dominios de código.
    10. Un método conforme a cualquiera de las reivindicaciones 1 a 9, en donde uno o más primeros dominios de código asociados a un primer proveedor de servicios pueden ser habilitados para operación regular por el proveedor de servicios de personalización independientemente de la habilitación para operación regular de otros uno o más primeros dominios de código asociados a un segundo proveedor de servicios.
    11. Un método asociado con el uso de un dispositivo móvil de un usuario en relación a la personalización de seguridad de una aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario, la aplicación software protegida de dispositivo móvil previamente generada por un proveedor de servicios de personalización en un estado de seguridad personalizada usando una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad, la aplicación protegida incluyendo varios dominios de código, relativos a uno o más proveedores de servicios, donde uno o más primeros dominios de código quedan vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad asociada al registro de personalización de seguridad, el método incluyendo:
    solicitando desde el dispositivo móvil del usuario una aplicación software de dispositivo móvil a un servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada;
    recibiendo desde el servidor de distribución y a continuación instalando por uno o más dispositivos de procesamiento en el dispositivo móvil la aplicación software protegida de dispositivo móvil en un estado de seguridad no-personalizada, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código están deshabilitados para operación regular;
    enviando desde el dispositivo móvil del usuario una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estado en un estado de seguridad no-personalizada;
    recibiendo datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no-personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
    12. Un método conforme a la reivindicación 11, en donde solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código son enviadas desde el dispositivo móvil del usuario al proveedor de servicios de personalización, cada solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario son recibidos en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
    13. Un método conforme a la reivindicación 12, en donde al menos uno del otro uno o más primeros dominios de código está vinculado en términos de seguridad a uno o más primeros dominios de código a través de la personalización de seguridad, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más primeros dominios de código y que son requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular.
    14. Un método conforme a la reivindicación 13, en donde al menos parte de los parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código requeridos para habilitar el al menos uno del otro uno o más primeros dominios de código para operación regular están disponibles en una parte de la base de datos de la aplicación software protegida de dispositivo móvil que está asociada a uno o más primeros dominios de código que han sido previamente habilitados para operación regular.
    15. Un método conforme a cualquiera de las reivindicaciones 11 a 14, en donde el uno o más primeros dominios de código habilitados mediante primeros datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un primer usuario son diferentes que los uno o más primeros dominios de código habilitados mediante segundos datos de personalización de seguridad recibidos en la aplicación software protegida de dispositivo móvil instalada en un dispositivo móvil de un segundo usuario.
    16. Un método conforme a cualquiera de las reivindicaciones 11 a 15, en donde los datos de personalización de seguridad recibidos en el dispositivo móvil de un primer usuario, los datos habilitando en la aplicación uno o más primeros dominios de código para operación regular y asociados a un primer registro de personalización de seguridad de ciclo de vida que incluye primeros parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código, son diferentes que los datos de personalización de seguridad recibidos en el dispositivo móvil de un segundo usuario, los datos habilitando en la aplicación uno o más primeros dominios de código para operación regular y asociados a un segundo registro de personalización de seguridad de ciclo de vida que incluye segundos parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código.
    17. Un medio leíble no transitorio de ordenador almacenando código leíble de programa de ordenador para causar un procesador de un dispositivo móvil de un usuario realizar un método asociado a la personalización de seguridad de una aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario, la aplicación software protegida de dispositivo móvil previamente generada por un proveedor de servicios de personalización en un estado de seguridad personalizada usando una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad, la aplicación protegida incluyendo varios dominios de código, relativos a uno o más proveedores de servicios, donde uno o más primeros dominios de código quedan vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad asociada al registro de personalización de seguridad, el método incluyendo:
    solicitando desde el dispositivo móvil del usuario una aplicación software de dispositivo móvil a un servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no-personalizada;
    recibiendo desde el servidor de distribución y a continuación instalando por uno o más dispositivos de procesamiento en el dispositivo móvil la aplicación software protegida de dispositivo móvil en un estado de seguridad no-personalizada, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código están deshabilitados para operación regular;
    enviando desde el dispositivo móvil del usuario una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estado en un estado de seguridad no-personalizada;
    recibiendo datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no-personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
    18. Un medio leíble no transitorio de ordenador almacenando código leíble de programa de ordenador conforme a la reivindicación 17 que causa el procesador enviando solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código desde el dispositivo móvil del usuario al proveedor de servicios de personalización, cada solicitud siendo lanzada por uno o más dispositivos de procesamiento utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y recibiendo datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
    19. Un dispositivo móvil de un usuario asociado con la personalización de seguridad de una aplicación software protegida de dispositivo móvil en el dispositivo móvil del usuario, la aplicación software protegida de dispositivo móvil previamente generada por un proveedor de servicios de personalización en un estado de seguridad personalizada usando una aplicación software de dispositivo móvil, un registro de personalización de seguridad y software de protección de seguridad, la aplicación protegida incluyendo varios dominios de código, relativos a uno o más proveedores de servicios, donde uno o más primeros dominios de código quedan vinculados en términos de seguridad a uno o más segundos dominios de código a través de la personalización de seguridad asociada al registro de personalización de seguridad, el dispositivo móvil incluyendo:
    un medio de almacenamiento electrónico que almacena datos de personalización de seguridad; y un procesador adaptado a:
    solicitar una aplicación software de dispositivo móvil a un servidor de distribución, el servidor de distribución almacenando en una o más memorias la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no personalizada;
    recibir desde el servidor de distribución y a continuación instalar en el dispositivo móvil la aplicación software protegida de dispositivo móvil en un estado de seguridad no-personalizada, en donde en dicho estado de personalización de seguridad pendiente los uno o más primeros dominios de código estas deshabilitados para operación regular;
    enviar una solicitud para una personalización de seguridad de al menos uno de los uno o más primeros dominios de código, la solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más segundos dominios de código de la aplicación software protegida de dispositivo móvil estando en un estado de seguridad no personalizada;
    recibir datos de personalización de seguridad asociados a un registro de personalización de seguridad de ciclo de vida que es relativo al dispositivo móvil del usuario desde el proveedor de servicios de personalización, los datos de personalización de seguridad habilitando en la aplicación software protegida de dispositivo móvil no-personalizada en seguridad al menos uno de los uno o más primeros dominios de código para operación regular, dicha personalización relativa a parámetros de seguridad y/o reglas de ofuscación y/o datos de checksums de código que están al menos parcialmente disponibles en los uno o más segundos dominios de código y que son requeridos para habilitar el al menos uno de los uno o más primeros dominios de código para operación regular.
    20. Un dispositivo móvil de un usuario conforme a la reivindicación 19, en donde el procesador está adaptado para enviar solicitudes sucesivas para una personalización de seguridad de al menos otro uno o más primeros dominios de código desde el dispositivo móvil del usuario al proveedor de servicios de personalización, cada solicitud siendo lanzada utilizando código ejecutable perteneciente a uno de los uno o más primeros dominios de código que han sido previamente habilitados para operación regular, y para recibir datos de personalización de seguridad asociados al registro de personalización de seguridad de ciclo de vida relativo al dispositivo móvil del usuario en la aplicación software protegida de dispositivo móvil parcialmente personalizada en seguridad, los datos de personalización de seguridad habilitando en la aplicación para operación regular el al menos otro uno o más primeros dominios de código que está asociado a la solicitud particular.
ES16178926T 2016-07-11 2016-07-11 Protección de seguridad de aplicaciones de dispositivos móviles basada en personalización y vinculación segura de dominios de código Active ES2814877T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP16178926.8A EP3270310B1 (en) 2016-07-11 2016-07-11 Mobile device applications security protection based on personalization and secured code domains pairing

Publications (1)

Publication Number Publication Date
ES2814877T3 true ES2814877T3 (es) 2021-03-29

Family

ID=56550696

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16178926T Active ES2814877T3 (es) 2016-07-11 2016-07-11 Protección de seguridad de aplicaciones de dispositivos móviles basada en personalización y vinculación segura de dominios de código

Country Status (2)

Country Link
EP (1) EP3270310B1 (es)
ES (1) ES2814877T3 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4053722B1 (en) * 2021-03-01 2023-11-29 Irdeto B.V. Secured computer code and systems, methods, and storage media for creating the secured computer code from original computer code
US20230096677A1 (en) * 2021-09-25 2023-03-30 Michael Ojomo Obfuscated And Secured Computer-Executable Source Code

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130124606A1 (en) * 2011-11-14 2013-05-16 Boopsie, Inc. Automatic personalization of downloadable mobile apps
ES2545974B1 (es) * 2014-03-17 2016-04-27 Bankinter, S.A. Sistema de protección automático y personalizado para aplicaciones móviles

Also Published As

Publication number Publication date
EP3270310B1 (en) 2020-06-10
EP3270310A1 (en) 2018-01-17

Similar Documents

Publication Publication Date Title
CN108781210B (zh) 具有可信执行环境的移动设备
US7886355B2 (en) Subsidy lock enabled handset device with asymmetric verification unlocking control and method thereof
CN109313690B (zh) 自包含的加密引导策略验证
US10292049B2 (en) Enabling a software application to be executed on a mobile station
US9270466B2 (en) System and method for temporary secure boot of an electronic device
KR100851631B1 (ko) 보안 모드 제어 메모리
ES2385565T3 (es) Sistema y método de firma mediante código por software
US7797545B2 (en) System and method for registering entities for code signing services
JP4912879B2 (ja) プロセッサの保護された資源へのアクセスに対するセキュリティ保護方法
EP2063378B1 (en) Telecommunications device security
RU2445689C2 (ru) Способ повышения ограничения доступа к программному обеспечению
CN110688660B (zh) 一种终端安全启动的方法及装置、存储介质
CN111199058B (zh) 用于确保数据的完整性和机密性的系统和方法
CN109660353A (zh) 一种应用程序安装方法及装置
JP6199712B2 (ja) 通信端末装置、通信端末関連付け方法、及びコンピュータプログラム
ES2814877T3 (es) Protección de seguridad de aplicaciones de dispositivos móviles basada en personalización y vinculación segura de dominios de código
KR20070059891A (ko) 어플리케이션 인증 보안 시스템 및 그 인증 보안 방법
CN109784072B (zh) 一种安全文件管理方法和系统
JP6517435B2 (ja) アプリケーションを管理する方法
US10367644B2 (en) Methods for managing content, computer program products and secure element
CN107862209B (zh) 一种文件加解密方法、移动终端和具有存储功能的装置
CN117063174A (zh) 用于通过基于app的身份的app间相互信任的安全模块及方法
CN114491682A (zh) 虚拟订户识别模块和虚拟智能卡
KR101350438B1 (ko) 모바일기기 내의 se를 이용하는 전자서명 시스템
CN111611551A (zh) 一种基于国密算法的动态链接库保护方法及其系统