Modelo no determinista para la auto-verificación de ...rua.ua.es/dspace/bitstream/10045/28518/1/tesis_yulier.pdf · Quiero agradecer profunda y sinceramente a mis directores de tesis,

MODELO NO DETERMINISTA PARA LA AUTO-VERIFICACIÓN DE INTEGRIDAD DE COMPONENTES DE SOFTWARE

Yulier Nuñez Musa

http://www.ua.es/

http://www.wltallerdigital.com/

yulier nuñez musa

M O D E L O N O D E T E R M I N I S TA PA R A L AA U T O - V E R I F I C A C I Ó N D E I N T E G R I D A D D E

C O M P O N E N T E S D E S O F T WA R E

Universidad de Alicante

memoria de tesis doctoral

M O D E L O N O D E T E R M I N I S TA PA R A L AA U T O - V E R I F I C A C I Ó N D E I N T E G R I D A D D E

C O M P O N E N T E S D E S O F T WA R E

yulier nuñez musa

DirectoresDr. Sergio A. Cuenca AsensiDr. Roberto Sepúlveda Lima

Departamento de Tecnología Informática y ComputaciónEscuela Politécnica Superior

Enero 2013

Yulier Nuñez Musa: Modelo no determinista para la auto-verificación deintegridad de componentes de software, Enero 2013

A mis padres y mi hermana, por su eterno amor...

A G R A D E C I M I E N T O S

Quiero agradecer a todas las personas que de una forma u otra hancontribuido a mi formación profesional y personal, que me han guia-do y acompañado hasta esta meta, en una carrera que comencé siendoniño y que hoy he logrado vencer.

Quiero agradecer profunda y sinceramente a mis directores de tesis,Sergio y Roberto, por todo el conocimiento que me han transmitidoen el transcurso del desarrollo de esta tesis. Por constituir una guíaen mi formación profesional y personal. Por brindarme su amistad yayuda incondicional. A ellos quiero expresarles mi profunda gratitud,pues sin su apoyo no hubiese sido capaz de llegar al final de estaempresa.

Le agradezco Francisco Maciá por el apoyo me ha brindado du-rante todo el tiempo que he estado acá y por ofrecerme su amistadincondicional.

Al Departamento de Tecnología Informática y Computación (DTIC)de la Universidad de Alicante y al Proyecto Habana, por hacer posiblelas estancias en la Universidad de Alicante en tiempos difíciles, locual ha sido decisivo para realizar satisfactoriamente esta tesis.

A la facultad de Ingeniería Informática de la CUJAE y al Comple-jo de Investigaciones Tecnológicas Integradas - CITI. Por apoyarmey animarme a realizar estos estudios. Por confiar y apreciar el tra-bajo que he realizado. Por brindarme soluciones a problemas quehubiesen atentado negativamente contra el éxito de mis estudios ysuperación profesional.

A los chicos del Programa de Seguridad del CITI, que más quecompañeros de trabajo, son entrañables amigos. Por hacerme la vidamás feliz y lograr que el trabajo sea una diversión.

A todos mis amigos, por compartirme su amistad, tanto en las bue-nas como en las malas, por apoyarme y darme ánimo en todo mo-mento.

Más que agradecer, quiero compartir con júbilo y alegría con mifamilia, en especial mis padres y mi hermana, todo el éxito alcanzado

vii

durante el desarrollo de la tesis. Por haber estado ahí siempre, porhacer que este trabajo fuera más fácil de llevar con su apoyo. Por sucariño, por su amor, por haber hecho de mí un hombre de bien.

Quiero dar gracias a Dios, por ser mi guía espiritual, por no dejar-me flaquear en los momentos difíciles, por permitirme ser una perso-na mejor cada día.

Alicante, 16 de enero de 2013.Yulier Nuñez Musa.

viii

R E S U M E N

Las pérdidas monetarias por concepto de piratería de software alcan-zan en la actualidad cifras millonarias. Por sólo citar un ejemplo, enel 2011 el valor comercial por este concepto ascendió a 63 billones dedólares, con un incremento de 4.2 billones con respecto al año ante-rior. En este ámbito, el software comercializado es sometido a ataquesy como resultado, usuarios ilegítimos pueden hacer uso del mismo.

Una vía para mitigar este problema desde el punto de vista tec-nológico, es el empleo de técnicas de protección de software, entrelas que se encuentran la ofuscación, el cifrado, las marcas de aguay la auto-verificación de integridad, entre otros. Dichas técnicas noson totalmente efectivas, debido principalmente a que la ejecucióndel software se realiza en una arquitectura insegura, sobre la que elatacante tiene un control total.

La presente tesis se centra en las técnicas de protección dirigidas alcontrol de integridad en ambientes de ejecución inseguros, específica-mente la técnica de auto-verificación de integridad, que ofrece resis-tencia ante ataques dinámicos. Una limitante de esta técnica es quepor sí sola no puede garantizar su privacidad, por lo que es necesariocombinarla con otras técnicas para lograr dicho fin. Varias propuestasestán dirigidas a complementar la auto-verificación de integridad contécnicas de ofuscación estructurales. Sin embargo, esto no es suficien-te para ofrecer una alta resistencia ante ataques dinámicos, por lo queademás es necesario incorporar una ofuscación funcional.

En este contexto, se propone un modelo no determinista para laverificación de integridad de componentes de software. El modelo sebasa en una red de auto-verificación, constituida por un componentede detección y un componente de respuesta. Ambos tienen un com-portamiento no determinista, por lo que tanto las detecciones comolas respuestas se ejecutan con cierta probabilidad.

Igualmente, y ante la carencia de estrategias consensuadas para laestimación del grado de protección que ofrecen estos mecanismos, seha optado por proponer un novedoso modelo de evaluación. En él se

ix

combina el concepto de Árbol de Ataque con aspectos de la Teoríade la Información, de forma que la estrategia es escalable y al mismotiempo tiene en cuenta el no determinismo de la red.

Por último, y como tercera contribución significativa del trabajo, sehan establecido las directrices para el establecimiento de una Infra-estructura de Protección de Software (Software Protection Infrastructu-re (SPI)). Dada la complejidad y el coste asociado a la incorporaciónde un mecanismo de protección en el proceso de desarrollo de soft-ware, la SPI permite simplificar y abaratar su integración mediante laaplicación automatizada de las mismas durante el proceso de compi-lación del software.

La implementación de una SPI básica, permitió generar un prototi-po de prueba del modelo no determinista y realizar un conjunto deevaluaciones experimentales aplicando para ello el modelo de evalua-ción propuesto. Los resultados indican una mejora de dos órdenes demagnitud en la resistencia y nivel de ofuscación funcional, respecto aun modelo equivalente de comportamiento determinista.

Al respecto, se pudo concluir que un comportamiento no determi-nista es acertado tanto para retardar un ataque exitoso, como paraminimizar el nivel de fuga de información. Este resultado es aplica-ble a la mejora de la resistencia ante ataques dinámicos y se presumeque pueda ser extendido a otras técnicas de protección.

Por otra parte, la infraestructura propuesta abre un espacio de in-vestigación para la protección masiva de software, minimizando con-siderablemente el coste asociado a esta actividad y potenciando laespecialización en las distintas disciplinas involucradas.

x

A B S T R A C T

Nowadays, the financial loss caused by software piracy reaches tomillions of dollars. For example, in 2011 the estimated value by thisconcept is considered as 63 billion dollars, 4.2 billion more than theprevious year. That is, the software is attacked successfully and theillegitimate users can make use of it.

Software protection techniques, such as obfuscation, encryption,watermarking and self-checking integrity, among others, are appliedfor mitigating this problem. These techniques are not completely ef-fective, because software runs on insecure architectures, where theattacker has full control.

This thesis is addressed to the self-checking technique, for provid-ing software’s resistance to dynamic attacks. This technique can notensure privacy by itself, so it is necessary to combine it with othersmechanisms to achieve this. The structural obfuscation that differentproposals have defined is not sufficient to provide high resistance todynamic attacks. In this case, obfuscation, from a functional point ofview, is incorporated.

A non-deterministic model for integrity verification of softwarecomponents is proposed. It is based into a self-checking network,composed by a detection and a response component. Both compo-nents have a non-deterministic behavior, that is, detections and re-sponses are executed with certain probability.

In the absence of evaluation strategies commonly accepted, the con-ceptual combination of Attack Tree with certain aspects of the Infor-mation Theory to get an estimate of the level of security achieved hasbeen established.

Given the complexity and cost for incorporating a protection mech-anism into the software development life-cycle, a general infrastruc-ture design for automating process protection is proposed. This in-frastructure allows the cost reduction for developing and applyingsoftware protection techniques, by inserting the protection processinto the component’s compilation phase.

xi

A non-deterministic test model prototype has been generated byimplementing a subset of the infrastructure components. It has al-lowed to apply a group of experiments for valuating the evaluationmodel proposed. The results indicate an improvement of two ordersof magnitude in resistance and information leakage when softwareare under attacks, compared with an equivalent model that exhibitdeterministic behavior.

In this regard, could be concluded that a non-deterministic behav-ior is successful, for delaying a successful attack, and for minimizingthe level of information leakage. This result was applied only to im-prove resistance to dynamic attacks but it is presumed that it couldbe extended to other protection techniques.

On the other hand, the proposed infrastructure opens a researcharea for the massive software protection, for minimizing the cost ofthis activity and for exploiting the specialization of developers withknowledge in security’s area.

xii

Í N D I C E G E N E R A L

1 introducción 1

1.1 Preámbulo 1

1.2 Motivación 2

1.3 Antecedentes 6

1.4 Problema, hipótesis y objetivos 8

1.5 Metodología y plan de trabajo 10

1.6 Estructura de la tesis 11

2 ámbito del problema 13

2.1 Piratería de software 13

2.2 Atributos de seguridad 17

2.2.1 Privacidad 18

2.2.2 Integridad 18

2.2.3 Disponibilidad 19

2.3 Modelo de amenazas 20

2.3.1 Red 20

2.3.2 Interno 21

2.3.3 Local 21

2.4 Ataque 21

2.4.1 Inspección 22

2.4.2 Manipulación 24

2.4.3 Automatización 28

2.5 Conclusiones 29

3 estado actual de las técnicas de auto-verificación

de integridad 31

3.1 Auto-verificación de integridad 32

3.2 Componente de detección de modificación 34

3.2.1 Objeto de la verificación 35

3.2.2 Procedimiento de verificación 39

3.3 Componente de respuesta ante modificación 42

3.3.1 Ubicación de la respuesta 43

3.3.2 Tipos de respuesta 44

3.4 Privacidad 46

3.4.1 Ofuscación sintáctica 47

xiii

xiv índice general

3.4.2 Ofuscación semántica 48

3.5 Evaluación de la seguridad 50

3.5.1 Árboles de ataque 51

3.5.2 Eval. cuantitativa del flujo de inf. 52

3.6 Conclusiones 54

4 modelo no determinista para la auto-verificación

de integridad 57

4.1 Requisitos de seguridad 57

4.2 Red de auto-verificación de integridad no determinis-ta 58

4.2.1 Componente de detección 60

4.2.2 Componente de respuesta 63

4.2.3 Red de auto-verificación 65

4.2.4 Integración de la red AVI 67

4.2.5 Ejemplo de integración de una red AVI no de-terminista 68

4.3 Análisis funcional del modelo propuesto 76

4.4 Conclusiones 78

5 modelo para la evaluación de la seguridad 79

5.1 Árbol de ataque 80

5.1.1 Generación de los casos de prueba 81

5.1.2 Localización de los nodos de la red 84

5.1.3 Manipulación de los nodos 90

5.1.4 Validación del ataque 90

5.2 Evaluación del nivel de ofuscación de la red AVI nodeterminista 92

5.2.1 Cálculo de la fuga de información 92

5.2.2 Métrica de ofuscación 96

5.2.3 Estimación del umbral de ataque 97

5.3 Conclusiones 100

6 infraestructura para la protección de softwa-re 101

6.1 Definición y requisitos 101

6.2 Servicios 104

6.3 Componentes 106

6.3.1 Mecanismo de protección 106

6.3.2 Plataforma de Protección 108

índice general xv

6.3.3 Entidad para el diseño de algoritmos de protec-ción 110

6.3.4 Entidad para el desarrollo de componentes deprotección 111

6.3.5 Entidad para la gestión de protecciones 113

6.3.6 Entidades finales 113

6.3.7 Soporte 114

6.4 Procesos 115

6.4.1 Solicitud 115

6.4.2 Protección 116

6.4.3 Revocación 116

6.5 Implementación de una SPI basada en redes AVI 116

6.5.1 Desarrollo de la plataforma de protección 117

6.5.2 Desarrollo del componente de protección basa-do en AVI 121


7 evaluación experimental 127

7.1 Configuración del mecanismo de protección 128

7.1.1 Planificación del experimento 129

7.1.2 Escrutinio de los factores 133

7.1.3 Cuantificación de los efectos principales 138

7.2 Evaluación del nivel de ofuscación 147

7.3 Evaluación de la disponibilidad 148

7.3.1 Sobrecarga del tamaño del código 148

7.3.2 Sobrecarga del tiempo de ejecución 151

7.4 Evaluación de la seguridad 153

7.4.1 Planificación del experimento 153

7.4.2 Casos de prueba 157

7.4.3 Localización de los nodos de verificación 160

7.4.4 Manipulación de los nodos de verificación 162

7.4.5 Comprobación de la manipulación 162

7.5 Proceso de config. del mecanismo de prot. 163


8 conclusiones y trabajos futuros 169

8.1 Conclusiones generales 169

8.2 Principales aportaciones 171

8.2.1 Dimensión teórica 171

xvi índice general

8.2.2 Dimensión de evaluación del planteamiento teó-rico 172

8.2.3 Dimensión práctica 172

8.3 Publicaciones 172

8.4 Trabajo futuro 173

8.4.1 Dimensión teórica 173

8.4.2 Dimensión de evaluación del planteamiento teó-rico 174

8.4.3 Dimensión práctica 174

a elementos de la teoría de la información 175

a.1 Entropía de Shannon 175

a.2 Entropía condicional y entropía conjunta 175

a.3 Información mutua 176

a.4 Canal de Comunicación 178

b información mutua del canal 181

c resultados de la evaluación experimental 183

d validación del simulador 187

bibliografía 191

Í N D I C E D E F I G U R A S

Figura 1 Tasa de piratería a nivel mundial 3

Figura 2 Valor comercial de software sin licencia 4

Figura 3 Escenario de piratería de software. 14

Figura 4 Proceso de ingeniería inversa aplicado en la pi-ratería de software. 22

Figura 5 Proceso de inspección. 23

Figura 6 Proceso de manipulación. 25

Figura 7 Proceso de automatización. 29

Figura 8 Clasificación de los mecanismos de auto-verif.de int. 33

Figura 9 Clasificación del mecanismo de detección. 35

Figura 10 Clasificación del mecanismo de respuesta. 42

Figura 11 Proceso de auto-verificación de integridad. 59

Figura 12 Subproceso de detección de modificación. 61

Figura 13 Tipos de respuesta. 64

Figura 14 Grafo de Control de Flujo de los métodos delprograma 1. 70

Figura 15 Ej. de grafo de verificación y respuesta. 73

Figura 16 GCF protegidos de los métodos del programa1. 75

Figura 17 Grafos de verificación y respuesta incorpora-dos a los métodos. 76

Figura 18 Árbol de ataque del modelo de protección pro-puesto. 80

Figura 19 Canal de información del ataque sobre un no-do. 93

Figura 20 Cálculo de I(A;R) para diferentes valores dep(e) y p. 95

Figura 21 Certeza de umbral de ataque para distintas pro-babilidades de respuesta. 99

Figura 22 Infraestructura para la protección de softwa-re. 103

xvii

xviii Índice de figuras

Figura 23 Diagrama de clases del Mecanismo de Protec-ción. 108

Figura 24 Plataforma de protección. 117

Figura 25 Proceso de compilación. 118

Figura 26 Proceso de compilación aplicando la protec-ción. 118

Figura 27 Diagrama de las clases principales de la plata-forma de protección. 119

Figura 28 Diagrama de secuencia del proceso de protec-ción. 120

Figura 29 Diagrama de componentes de la plataforma deprotección. 121

Figura 30 Proceso de protección. 122

Figura 31 Gráfica normal de efectos estandarizados paraPR. 134

Figura 32 Gráfica de Pareto de efectos estandarizados pa-ra PR. 135

Figura 33 Gráfica de efectos estand. para ST 137

Figura 34 Gráfica de efectos princ. para el Nodo 1. 138

Figura 35 Gráfica de interacción entre factores para PRdel Nodo 1. 139

Figura 36 Gráfica de cubos para el Nodo 1. 140







Figura 43 Gráfica de efectos principales para ST. 145

Figura 44 Gráfica de int. entre fac. para ST. 146

Figura 45 Sobrecarga del tamaño impuesto por el meca-nismo de protección. 149

Figura 46 Sobrecarga del tamaño para distintas aplica-ciones. 149

Figura 47 Diagrama de cajas de las configuraciones paracada aplicación. 150

Figura 48 Sobrecarga de tiempo medio de todos los casosde prueba para cada configuración. 151

Figura 49 Sobrecarga del tiempo de ejecución para los ca-sos por encima de la media. 152

Figura 50 Cobertura de código del soft. de prueba. 157

Figura 51 Porcentaje de nodos no cubiertos por los casosde prueba. 158

Figura 52 Gráfica de dispersión de cobertura de código yejecución de nodos. 159

Figura 53 Proceso de configuración del mecanismo de pro-tección. 164

Figura 54 Canal de información. 178

Figura 55 Valores de p de los experimentos. 189

Í N D I C E D E TA B L A S

Tabla 1 Técnicas de protección. 107

Tabla 2 Dependencia del lenguaje y arquitectura. 109

Tabla 3 Niveles por factor. 131

Tabla 4 Factores e interacciones significativos. 136

Tabla 5 Niveles de cada factor para minimizar PR. 144

Tabla 6 Configuración del mecanismo de protección. 146

Tabla 7 Fuga de información (bits). 147

Tabla 8 Configuración del mecanismo de protección pa-ra validar la simulación. 155

Tabla 9 Nodos Localizados ( %). 156

Tabla 10 Tiempo de localización (horas). 156

Tabla 11 Coeficientes de correlación de cobertura de có-digo y ejecución de nodos. 159

Tabla 12 Umbral de localización requerido para locali-zar los nodos de verificación. 161

xix

Tabla 13 Coste asociado de la localización de los no-dos de verificación relativo al caso determinis-ta. 161

Tabla 14 Coste asociado a comprobación de la manipu-lación relativo al caso determinista. 163

Tabla 15 Factores influyentes en la seguridad y disponi-bilidad del mecanismo de protección. 163

Tabla 17 Distribución de probabilidad conjunta p (h,o)de M1. 177

Tabla 18 Descripción de un canal de información. 179

Tabla 19 Cálculo de I(A;R) para diferentes valores dep(e) y p. 182

Tabla 21 Prueba t de dos muestras para el porcentaje denodos localizados. 188

Tabla 22 Prueba t de dos muestras para el tiempo delocalización. 188

Í N D I C E D E A L G O R I T M O S

Algoritmo 1 Algoritmo de verificación de integridad. 62

Algoritmo 2 Algoritmo de respuesta. 64

Algoritmo 3 Integración de la red AVI. 68

Algoritmo 4 Algoritmo para generar el oráculo de prueba. 85

Algoritmo 5 Localización de los nodos mediante depuracióninversa. 86

Algoritmo 6 Localización de los nodos mediante particiona-do lógico del software. 88

Algoritmo 7 Validación de la manipulación. 91

Algoritmo 8 Configuración del mecanismo de protección. 165

xx

lista de acrónimos xxi

L I S TA D E A C R Ó N I M O S

AVI Auto-verificación de Integridad

BSA Business Software Alliance

CDF Cumulative Distribution Function

DAG Directed Acyclic Graphs

DOE Design of Experiments

EA Esfuerzo del atacante

FLA Fourier-Learning Approximations

GCF Grafo de Control de Flujo

ICE Integrity Checking Expressions

IR Intermediate representation

IVK Integrity Verification Kernel

OH Oblivious Hashing

OID Object identifier

PR Probabilidad global de Respuesta

PVC Probabilistic Verification conditions

QIF Quantitative Information Flow

SC Sobrecarga de Código

SPI Software Protection Infrastructure

ST Sobrecarga de Tiempo

1I N T R O D U C C I Ó N

Este capítulo resume los principales aspectos de la presente investi-gación doctoral. Está estructurado en ocho secciones, las cuales serelacionan a continuación. En la Sección 1.1 se enmarca el trabajode investigación. Seguidamente, en la Sección 1.2 se exponen los ele-mentos que motivaron este trabajo. En la Sección 1.3 se relacionanbrevemente las principales propuestas en el ámbito de la protecciónde software, específicamente los basados en auto-verificación de inte-gridad. A continuación, en la Sección 1.4, se plantea el problema deinvestigación a tratar, basado en las limitaciones previamente identi-ficadas. Se enuncia la hipótesis de partida de la investigación y encorrespondencia, se enumeran los objetivos. Por último, en la Sección1.6, se expone la estructura del resto de esta memoria.

1.1 preámbulo

La presente memoria es el resultado de la tesis doctoral desarrolladaen el programa de doctorado Tecnologías de la sociedad de la información.Este programa está a cargo del Departamento de Tecnología Informáticay Computación – DTIC, de la Universidad de Alicante (España) y en élparticipan varias universidades cubanas, entre ellas, el Instituto Supe-rior Politécnico José Antonio Echeverría – CUJAE.

En esta investigación se aborda el problema de la ejecución de có-digo confiable en ambientes inseguros (no confiables) de ejecución,siendo el escenario principal que propicia la piratería de software(software piracy).

A diferencia de los códigos malignos (malwares), se entiende porcódigo confiable un componente ejecutable de software cuyo origen

1

2 introducción

es conocido y se le otorga un alto nivel de confianza. El resultado desu ejecución, no daña de forma alguna el estado del ordenador, elsistema operativo, las aplicaciones, ni los datos manejados por estos.Así mismo, se considera que el ambiente de ejecución es inseguro,cuando la seguridad del código confiable se ve afectada en términosde integridad y privacidad.

Se considera que este es un problema de investigación abierto parael que todavía no se ha encontrado una solución completa, debidoen gran parte a la arquitectura, inherentemente insegura, de los pro-cesadores actuales. Las diferentes aproximaciones propuestas estándirigidas a minimizar el impacto que puede provocar este problemaen función del contexto de aplicación.

La tesis se ha desarrollado en el marco del Proyecto de Seguridad Tec-nológica, llevado a cabo por el Complejo de Investigaciones TecnológicasIntegradas - CITI en colaboración con la Facultad de Ingeniería Informá-tica perteneciente a la CUJAE. Dicho proyecto tiene como objetivodesarrollar componentes y soluciones de software y hardware quegaranticen la seguridad de los sistemas informáticos.

1.2 motivación

La industria de software a nivel mundial ha alcanzado niveles deproducción no imaginados; cada persona, entidad, industria deseaautomatizar sus procesos y flujos de información con el objetivo dealcanzar mejores resultados productivos en tiempos más cortos aba-ratando los costos.

Dada la competencia existente y la urgencia en dar respuesta a losdistintos tipos de clientes, los desarrolladores de software se centranen dar cumplimiento a los requisitos funcionales solicitados, dejandoen el mayor de los casos, los elementos de seguridad en un segundoplano. Esto se traduce en que no se preste la debida atención a losrequisitos de seguridad desde las etapas tempranas del desarrollodel software.

Dicha situación trae como consecuencia que las aplicaciones sal-gan al mercado, si bien libres de errores funcionales que devenganen vulnerabilidades, protegidas débilmente o desprovistas de meca-nismos de protección que brinden resistencia ante posibles ataques,

1.2 motivación 3

permitiendo que cualquier atacante con conocimientos mínimos deingeniería inversa (Eilam, 2005) pueda violentarlas sin mucho esfuer-zo.

Esta afirmación queda evidenciada observando los datos de la co-mercialización de software a nivel mundial. A pesar del auge signifi-cativo del software libre y de código abierto, los cuales representandel 12 al 22 % de las aplicaciones instaladas, aún existe un predomi-nio significativo en el mercado de los sistemas propietarios, lo cualesrepresentan del 35 al 45 %. El resto de las aplicaciones instaladas, al-rededor del 43 %, se corresponde con copias distribuidas de forma noautorizada (lo que se ha dado en llamar software pirata), constituyen-do un grave problema para esta industria (BSA, 2010).

Según el estudio sobre piratería de software a nivel global realizadopor la Business Software Alliance (BSA) (BSA, 2012), se reporta quela tasa de piratería de software1 en todo el mundo se mantuvo enun 42 % en el 2011, igual valor al año anterior (ver figura 1). Esteporcentaje se traduce en la pérdida de $63.4 billones de dólares en el2011 debido a estas prácticas ilegales (ver figura 2).

35% 35%38% 41% 43% 42% 42%

0%

10%

20%

30%

40%

50%

2005 2006 2007 2008 2009 2010 2011

Tasa de pirartería

Figura 1 Tasa de piratería a nivel mundial (2005-2011).

Para conseguir la distribución ilegal de un software generalmentees necesario realizar ciertas modificaciones sobre su código, de formaque se eliminen sus mecanismos de protección. Los procedimientospor los que se llevan a cabo estas modificaciones es a lo que se deno-

1 La tasa de piratería es la razón de unidades de software sin licencia entre la unidadesde software instaladas.

4 introducción

minan ataques. Estos procedimientos o ataques pueden variar segúnlas características del sistema donde dicha aplicación es ejecutada.A. Main (2003) y Aucsmith (1996) clasifican los ataques a través detres modelos de amenazas según la ubicación y privilegios del ata-cante sobre el sistema donde son ejecutadas las aplicaciones.

$34,48$39,70

$47,81$53,00 $51,41

$58,80$63,40

0 $10 $20 $30 $40 $50 $60 $70 $

2005 2006 2007 2008 2009 2010 2011

(Bill

ones d

e dó

lare

s)

Pérdidas

Figura 2 Valor comercial de software sin licencia (2005-2011).

En el primer y segundo modelo de amenaza, los ataques son efec-tuados de forma remota a través de la red (network threat model), ya seauna red externa o local, mediante la explotación de posibles vulnera-bilidades presentes en aplicaciones. En este modelo, las aplicacionesson ejecutadas en un ambiente seguro (trusted host) e inaccesible paraun atacante de forma local.

En el tercer modelo de amenaza, los ataques se realizan de formalocal en la propia máquina donde ocurre la ejecución del software(untrusted host threat model). Bajo este modelo, el ambiente de ejecu-ción del software se considera no confiable (untrusted host), pues elatacante cuenta con suficientes privilegios y herramientas para llevara cabo el análisis y modificación del software.

Es de interés de esta investigación centrarse en el modelo de amena-za de ambiente de ejecución no confiable (untrusted host threat model)pues es el modelo que propicia, desde el punto de vista tecnológico2,la piratería de software.

2 Son diversos los factores que favorecen la piratería de software. Vea p. ej. (Limayemet al., 2004).

1.2 motivación 5

Es necesario destacar que la protección de código ejecutable en unambiente de ejecución no confiable es un problema de investigaciónde alto interés en diversas áreas tales como las redes de sensoresinalámbricos (Chang and Shin, 2008; Das and Ho, 2011; Park andShin, 2005), código móvil en plataformas multi-agentes (Hashmi andBrooke, 2008, 2009; Price, 2008; Tsaur, 2012), o el firmware de hard-ware dedicado (Kim et al., 2012; Mao and Wolf, 2010), entre otros.

La arquitectura de los microprocesadores convencionales es intrín-secamente insegura (Mason, 2005) y compromete dos de los factoresmás importantes a la hora de proteger una aplicación: la privacidad yla integridad.

Se considera que un software mantiene su privacidad, cuando al ata-cante le resulta difícil realizar una inspección, análisis u observaciónsobre el mismo, con el objetivo de comprender su funcionamiento enun tiempo razonable. De garantizarse este atributo, el atacante tieneque resignarse a realizar un análisis de caja negra, observando el con-junto de pares de entradas y salidas para inferir el funcionamientointerno del software.

Por otra parte, la protección de la integridad va dirigida a detectarataques que modifiquen el funcionamiento de la aplicación. El ata-cante puede realizar modificaciones al azar, pero generalmente unataque contra la privacidad precede a un ataque contra la integridad.

Ambos ataques, pueden llevarse a cabo de forma estática o diná-mica. Un ataque estático se realiza sobre la aplicación mientras seencuentra en el medio de almacenamiento. En este tipo de ataque nose pueden apreciar los valores de los registros del proceso, la pila,zonas de memoria, etc. Para acceder a estos valores de la aplicación,se requiere un ataque dinámico sobre la misma mientras es ejecutadaen memoria. Es necesario destacar que un atacante obtiene muchamás información de la aplicación mediante un ataque dinámico quemediante uno estático.

Para evitar los ataques contra la privacidad y la integridad, seande forma estática o dinámica, es necesario dotar a los componentesde software, de mecanismos de protección que garanticen la preser-vación de estos atributos bajo un ambiente de ejecución no confiable.

La experiencia demuestra que hasta el momento no existe ningúnmecanismo de protección que permita garantizar los atributos de se-

6 introducción

guridad por un tiempo ilimitado. Resulta por tanto más realista, aspi-rar a obtener un período de resistencia ante ataques que sea suficientepara los intereses de los fabricantes de software.

Por citar un ejemplo, el período de mayor ganancia en el ciclo devida de un producto (Kotler and Armstrong, 2011) abarca desde suintroducción en el mercado hasta el inicio de la etapa de declive ode relanzamiento (en el caso del software correspondería con la apa-rición de una nueva versión). Garantizar la resistencia ante ataquesdurante este período puede considerarse un objetivo razonable paralas protecciones de software.

1.3 antecedentes

Acorde a la definición propuesta por Aucsmith, “(...) un software re-sistente a manipulación, es un software que es resistente a observa-ciones y modificaciones” (Aucsmith, 1996). Tomando esta definicióncomo referencia, un software resistente a manipulación (tamper resis-tant software) es capaz de garantizar sus atributos de privacidad eintegridad, mostrando un comportamiento o apariencia que retardael éxito de un ataque.

Para garantizar la privacidad, pueden emplearse técnicas de diver-sidad de código (Anckaert et al., 2004, 2007; Schrittwieser and Katzen-beisser, 2011), ofuscación (Collberg and Thomborson, 2002; Dalla Pre-da and Giacobazzi, 2009; Schrittwieser and Katzenbeisser, 2011), ci-frado (Cappaert et al., 2008; Chow et al., 2003; Michiels, 2010), auto-modificación de código (Cai et al., 2007; Giffin et al., 2005; Mavrogian-nopoulos et al., 2011) y técnicas anti-depuración (Lin et al., 2011; Yiet al., 2009).

Por otra parte, la integridad puede garantizarse mediante técnicasde auto-verificación de integridad (Horne et al., 2002), arquitectura dehardware seguras (Chhabra et al., 2009) o dispositivos de hardwarecomplementarios (Mason, 2005; MeiHong and JiQiang, 2009; yuanZheng and Liu, 2010) y en ocasiones, empleando marcas de agua detipo frágiles (Zhu et al., 2005).

De forma general, los mecanismos de protección se basan en técni-cas híbridas que garantizan tanto la privacidad como la integridad dela aplicación en una misma solución para lograr mejores niveles de

1.3 antecedentes 7

protección. Es usual que se empleen técnicas que proveen privacidad3

para garantizar integridad de forma colateral, dado que, si el atacan-te no es capaz de comprender el funcionamiento de una aplicación,entonces no puede modificarla de forma objetiva para satisfacer susnecesidades. El caso inverso, desarrollar un mecanismo de control deintegridad que a su vez, de forma implícita, garantice su propia pri-vacidad puede ser más difícil de lograr. Ténganse en cuenta que losalgoritmos de verificación de integridad no están concebidos para evi-tar ataques por inspección que atenten contra su propia privacidad4.

En sentido general, diferentes autores (Aucsmith, 1996; Chang andAtallah, 2002; Horne et al., 2002; Tan et al., 2007) proponen comple-mentar las técnicas de auto-verificación de integridad, con técnicasque garanticen privacidad (generalmente ofuscación y cifrado), paralograr sistemas resistentes a manipulación. Sin embargo, debido a laaparición de algunos resultados negativos en el área de la ofuscación(Barak et al., 2001; Goldwasser and Kalai, 2005) y cifrado de código(Billet et al., 2005; Goubin et al., 2007; Wyseur et al., 2007), parece ne-cesario identificar un mecanismo de auto-verificación no sólo desdeel punto de vista sintáctico (Jacob et al., 2007; Jin et al., 2005)5, sinotambién desde el semántico o del comportamiento (Anckaert et al.,2007; Dalla Preda and Giacobazzi, 2009; Dedic et al., 2007)6.

Además, existen indicios de que la definición de un mecanismopara la auto-verificación de integridad, con un comportamiento no-determinista, permite elevar su propio nivel de privacidad medianteuna ofuscación dinámica. Tal es el caso de la propuesta realizada porAucsmith (1996), al proponer varios hilos de ejecución en una mismaaplicación para confundir al atacante a la hora de determinar cuáles el hilo correcto a seguir. En la propuesta realizada por Tan et al.

3 Los algoritmos de cifrado empleados en criptografía, por ejemplo, no garantizanintegridad por sí solos (vea Menezes et al., 1996, sec. 9.6.5).

4 Un mecanismo de integridad garantiza la integridad de la aplicación a proteger,pero surge el problema de cómo garantizar la integridad y la privacidad del propiomecanismo de protección ante un ataque.

5 Se entiende por ofuscación sintáctica (de forma o estructural), a las técnicas quehacen más confusas las estructuras de una aplicación de cara al atacante, estas son:datos, instrucciones, métodos, clases, etc.

6 La ofuscación semántica (ver Collberg and Nagra, 2009, sec. 6.1) ofusca el compor-tamiento de la aplicación, fundamentalmente su grafo de control de flujo mediantetécnicas de auto-modificación (Cai et al., 2007) y diversidad (Anckaert et al., 2007).

8 introducción

(2007), se sugiere que los controles de integridad deben ser probabilís-ticos. Por su parte Dedic et al. (2007) presenta una propuesta basadaen un conjunto de comprobadores, diversificados y distribuidos alea-toriamente en la aplicación, para la verificación no-determinista deintegridad basada en un umbral de detección de modificaciones. Porúltimo, Anckaert et al. (2007) propone que los caminos de ejecuciónde una aplicación sean seleccionados de forma aleatoria mediante ladiversificación del Grafo de Control de Flujo, logrando un comporta-miento no-determinista de la misma.

1.4 problema , hipótesis y objetivos

Del análisis de los antecedentes se desprende que las actuales pro-puestas de auto-verificación de integridad que contemplan la ofusca-ción como vía para garantizar la privacidad del mecanismo de protec-ción, lo hacen desde el punto de vista estructural, lo cual es efectivoante análisis estáticos. Sin embargo, además de lograr una ofuscaciónestructural (sintáctica) del mecanismo de protección, es necesario ga-rantizar una ofuscación funcional (semántica) del mismo, con el ob-jetivo de aumentar la resistencia ante análisis dinámicos. Por tanto,se plantea como problema a resolver en la presente investigación, ladefinición de un mecanismo de control de integridad que garanticesu propia privacidad e integridad ante ataques dinámicos.

La hipótesis en la cual se fundamenta esta investigación, es la posi-bilidad de integrar un conjunto de buenas prácticas que sustenten eldiseño de un mecanismo viable para la protección de componentesde software, basada en un modelo de auto-verificación de integridadque garantice la ofuscación semántica del propio mecanismo a partirde un comportamiento no determinista. La viabilidad de la propuestase expresaría en los siguientes términos:

1. El coste de desarrollo y aplicación del mecanismo de protecciónes lo suficientemente bajo para que pueda ser adoptada por losdesarrolladores de software y no imponga una carga adicionalal coste y tiempo de desarrollo del producto.

1.4 problema , hipótesis y objetivos 9

2. El tiempo para llevar a cabo un ataque exitoso podrá ser ajusta-do según las necesidades del usuario (p. ej. para cubrir el perío-do de mayores ganancias en el ciclo de vida del producto).

Basándose en el problema identificado y la hipótesis formulada, seplantea como objetivo general de la investigación: desarrollar7 un mo-delo no determinista que permita la generación viable, en términosde seguridad y disponibilidad, de un mecanismo de auto-verificaciónde integridad que retarde el tiempo de un ataque dinámico exitososobre una aplicación y que garantice:

1. La integridad del software a proteger.

2. La integridad y privacidad del propio mecanismo de protección.

3. La inviabilidad de un ataque dinámico sobre el software o el meca-nismo de protección.

4. Un mínimo impacto en la disponibilidad del rendimiento delsoftware a proteger.

Para dar cumplimiento al objetivo general, se han identificado lossiguientes objetivos específicos:

1. Diseñar un modelo de protección no determinista basado en laauto-verificación de integridad con los siguientes atributos:

a) Seguridad distribuida.

b) Complementariedad entre la privacidad y el control de in-tegridad en un modelo único.

c) Adecuada flexibilidad que permita obtener distintas solu-ciones de compromiso (trade-offs) entre seguridad y dispo-nibilidad.

2. Proponer un modelo de evaluación de la seguridad basado enla aplicación de un conjunto conocido de ataques.

7 La acción de desarrollar en este contexto comprende de forma general: el diseño delmodelo teórico, la implementación de un prototipo de prueba y la validación a partirde resultados experimentales.

10 introducción

3. Proponer un infraestructura que permita el despliegue automá-tico de la protección.

4. Evaluar la seguridad y disponibilidad del modelo de protecciónpropuesto.

1.5 metodología y plan de trabajo

A continuación se listan las tareas que constituyen el plan de trabajode esta investigación. Las tareas se plantean concretamente para darcumplimiento a cada uno de los objetivos específicos trazados:

• Objetivo 1:

1. Estudio del ámbito del problema, lo cual comprende:

a) Piratería de software y modelo de amenaza que lo pro-picia.

b) Atributos de seguridad a garantizar en un software.

c) Comportamiento del atacante y tipos de ataques bajoel modelo de amenaza en cuestión.

2. Estudio del estado del arte de las técnicas de auto-verifica-ción de integridad, lo cual incluye:

a) Realización de una clasificación o taxonomía de los me-canismos de auto-verificación de integridad.

b) Estudio de las propuestas que combinan controles deintegridad y ofuscación.

3. Identificar los objetivos de diseño de seguridad que mar-que las pautas a seguir en la propuesta de modelo de auto-verificación de integridad.

4. Diseñar los componentes que conforman el mecanismo deprotección así como sus interconexiones.

• Objetivo 2:

1. Estudio de modelos que permitan cuantificar la seguridaddesde el punto de vista de control de integridad y ofusca-ción.

1.6 estructura de la tesis 11

2. Diseñar un modelo de evaluación de la seguridad que per-mita cuantificar:

a) La resistencia del modelo de protección propuesto an-te un ataque.

b) El nivel de ofuscación alcanzado.

• Objetivo 3:

1. Identificar los objetivos de diseño de seguridad y funciona-lidad de la infraestructura de protección.

2. Definir los servicios, componentes y procesos que confor-man la infraestructura de protección.

3. Diseñar una plataforma para la protección automatizadade software basada en el uso de compiladores.

• Objetivo 4:

1. Identificar los factores que permitan obtener la configura-ción más adecuada del mecanismo de protección para ma-ximizar el coste del ataque.

2. Aplicar el modelo de protección con la configuración de-terminada a una aplicación de prueba.

3. Realizar la simulación de un ataque y evaluar el coste delmismo aplicando el modelo de evaluación propuesto.

4. Realizar pruebas de disponibilidad de la aplicación prote-gida en cuanto a impacto en el rendimiento y consumo dememoria.

Como última tarea se plantea determinar las principales novedadesaportadas durante la investigación e identificar las líneas de trabajofuturo a seguir para dar continuidad a la investigación.

1.6 estructura de la tesis

El presente documento de tesis está estructurada en ocho capítulos. Acontinuación se brinda un resumen del contenido abordado en cadauno de estos:

12 introducción

• Capítulo 1. Introducción: este primer capítulo sintetiza los princi-pales aspectos metodológicos de la presente investigación doc-toral.

• Capítulo 2. Ámbito del problema: se abordan los principales ele-mentos conceptuales relacionados con el ámbito del problema.

• Capítulo 3. Estado de las técnicas de auto-verificación de integridad:se expone una revisión del estado actual de las técnicas de auto-verificación de integridad en el ámbito de la piratería de soft-ware y de los modelos de evaluación existentes que pueden seradoptados para evaluar la seguridad de dichas técnicas.

• Capítulo 4. Modelo para la auto-verificación de integridad no deter-minista: se propone un modelo de auto-verificación de integri-dad en el ámbito de la piratería de software, que incorporaelementos de ofuscación basando en un comportamiento no-determinista.

• Capítulo 5. Modelo para la evaluación de la seguridad: se proponeun modelo de evaluación de la seguridad basado en las nocio-nes de Árbol de Ataque y Teoría de la Información, que permitepara evaluar la seguridad del modelo de protección propuesto.

• Capítulo 6. Propuesta de infraestructura para la protección de aplica-ciones: se exponen los detalles iniciales de una propuesta de in-fraestructura de protección que permita acortar el ciclo de desa-rrollo de un software protegido, haciendo viable su uso.

• Capítulo 7. Evaluación empírica: se realiza un caso de estudiopara validar la solución propuesta mediante resultados experi-mentales obtenidos al aplicar el modelo de evaluación.

• Capítulo 8. Conclusiones y trabajos futuros: se exponen las con-clusiones generales resultantes de la investigación, se detallanlas principales aportaciones y por último se exponen las futuraslíneas de investigación a seguir.

Adicionalmente el documento cuanta con Referencias Bibliográfi-cas y Anexos.

2Á M B I T O D E L P R O B L E M A

En este capítulo se definen los principales elementos conceptualesque permiten la conducción de la presente investigación.

En la Sección 2.1 se explica de forma general como es llevada acabo la piratería de software, dado que es el problema principal quemotivó la presente investigación. Consecuentemente, se enumeran losprincipales elementos de diseño a tener en cuenta para el desarrollode un mecanismo de protección. Seguidamente en la Sección 2.2 semencionan los atributos de seguridad a garantizar en una aplicaciónpara evitar su distribución ilegal. En la Sección 2.3, se enuncian lascausas que propicia la piratería de software basada en las amenazasexistentes del actual modelo de distribución de software. Posterior-mente, en la sección 2.4 se modela cómo el atacante, basándose endicho modelo de amenaza, es capaz de conducir un ataque satisfac-torio mediante un proceso de ingeniería inversa. Por último, en laSección 2.5 se brindan las conclusiones del capítulo, derivadas delestudio realizado.

2.1 piratería de software

La piratería de software (software piracy) consiste en la copia o distri-bución no autorizada de software con derechos de autor (Limayemet al., 2004). Un escenario común de piratería de software puede servisto en la figura 3.

Inicialmente, el software a comercializar es desarrollado por unafábrica de software (1) bajo derechos de autor contenidos en algúntipo de licencia (End User License Agreement, EULA) que especifica lostérminos de comercialización y uso de cara al usuario legítimo, ya

13

14 ámbito del problema

sea una empresa (2) o un usuario corriente (5). La distribución delsoftware puede realizarse mediante algún medio de almacenamiento(CD’s o DVD’s), o bajo un esquema de comercialización en línea através de Internet.

Internet

Atacante (3)

Sitio web pirata (4)

Leyenda

Desarrollador de software

Usuario legítimoL

I

D

Empresa (2)

Fábrica de software (1)

Red doméstica (5)

Usuario ilegítimo

A AtacanteA

L

I

I

D

DD

L

L

I

Figura 3 Escenario de piratería de software.

Es usual que el software a comercializar esté disponible en una ver-sión de prueba o evaluación (trial/shareware software), con limitacionesde funcionalidad o disponibilidad. Un usuario legítimo puede adqui-rir directamente un software o usarlo por un período de prueba, enambos casos bajo una licencia que especifica los términos legales deuso y distribución.

El software a comercializar, pueden contar o no con algún mecanis-mo de protección más o menos robusto que intente garantizar su usolegal.

En este modelo de distribución de software, se pueden identificarcuatro roles fundamentales:

2.1 piratería de software 15

1. Desarrollador de software. Encargado de desarrollar y comer-cializar el software. Su objetivo, a nivel comercial, es maximizarlas ganancias.

2. Usuario legítimo. Usuario que recibe los beneficios de un soft-ware adquirido de forma legal.

3. Atacante. Posee las habilidades y herramientas para desactivarel mecanismo de protección de un software comercial.

4. Usuario ilegítimo. Usuario que desea recibir los beneficios deun software adquirido de forma ilegal.

Tomando esto como punto de partida, se pueden mencionar dife-rentes formas de piratería de software:

1. Piratería de usuario final. Conocida también como copia o usoilegal de software. Ocurre cuando un usuario legítimo, ya seaen una empresa (2) o una persona (5), ha adquirido un softwarede forma legal y realiza un número de copias indiscriminadasdel mismo sin estar contemplado en la licencia, por ejemplo, alinstalar un software en un número mayor ordenadores que lopermitido o compartir el disco de instalación con otro usuario.

2. Piratería en Internet. Se pone de manifiesto cuando un usuarioilegítimo descarga un software ilegal desde un sitio pirata enInternet (4), pudiéndose realizar de cuatro formas diferentes:

a) Descarga de un software legítimo. Consiste en publicar enun sitio pirata un software de procedencia legítima, paraser descargado y usado de forma indiscriminada. Pude serconsiderado una variante de piratería de usuario final, soloque la distribución no se realiza mediante un soporte físicode almacenamiento.

b) Descarga de software manipulado. Consiste en publicar enun sitio pirata un software de procedencia ilegítima. Unatacante (3) modifica deliberadamente el mecanismo decontrol de licencias de un software, generalmente de prue-ba, permitiendo su uso sin restricciones de funcionalidado disponibilidad.


c) Descarga de parche. En lugar de distribuir el software ma-nipulado, un atacante publica un programa, conocido co-mo parche (crack), que le permite a un usuario ilegítimodesactivar el mecanismo de control de licencias de un soft-ware para ser usado sin restricción de funcionalidad o dis-ponibilidad.

d) Descarga de licencia no válida. Es muy similar al anterior,solo que el atacante distribuye una licencia no válida, oun programa que genera licencias no válidas (keygen), quele permite a un usuario ilegítimo emplear un software sinrestricción de funcionalidad o disponibilidad.

3. Copia de propiedad intelectual. No se considera directamenteuna forma de piratería de software, pues el mismo no es dis-tribuido completamente de forma ilegal. En este caso se tratade copiar un algoritmo protegido bajo propiedad intelectual ycolocarlo en otro producto de software.

La existencia de estos tipos de piratería de software ha dado lugara la propuesta de diferentes mecanismos de protección, que persiguenobjetivos diferentes:

1. Protección contra copia. Evita la copia y uso indiscriminado deun software, ya sea de usuario final o mediante Internet. Selogra mediante la dependencia del software a un medio físi-co, más difícil de reproducir, generalmente un dispositivo dehardware específico (dongle) o a un medio de almacenamiento(floppy, CD o DVD) modificado adecuadamente para evitar sucopia.

2. Protección contra violación de software. Evita la violación demecanismos de protección de un software en sus diversas ma-nifestaciones tales como software manipulado directamente, lageneración de parches (cracks) o licencias no válidas. Se lografundamentalmente con técnicas de software resistentes a mani-pulación (software tamper resistant).

3. Protección de propiedad intelectual y derecho de autor. Evitala copia de algoritmos con derechos de autor contenidos en un

2.2 atributos de seguridad 17

software. Se logra combinando técnicas que demuestren el de-recho de autoría y técnicas de software resistentes a manipula-ción.

Para el desarrollo de un mecanismo de protección, se debe tener encuenta los siguientes aspectos:

1. Atributos de seguridad. Es necesario definir qué atributo de se-guridad del software se va a garantizar, lo que condiciona eltipo de mecanismo de protección a emplear. Por ejemplo, paragarantizar la privacidad de un software y evitar la copia de pro-piedad intelectual, se pueden emplear técnicas de ofuscación,unidas a marcas de agua para asegurar el derecho de autoría.

2. Modelo de amenazas. Es necesario definir cuáles son las ame-nazas existentes sobre el software a proteger, lo cual determinael tipo de mecanismo de protección a desarrollar. Por ejemplo,un mecanismo de control de integridad de software contra des-bordamiento de buffer, difiere del empleado para garantizar laintegridad de un software resistente a modificación, dado quelas amenazas varían de un caso a otro.

3. Ataques. Conocer la naturaleza del ataque permite identificarlos elementos que lo dificultan a la hora de diseñar el meca-nismo de protección. El tipo de ataque está condicionado porel modelo de amenaza y el atributo de seguridad a garantizar,lo cual condiciona a su vez el diseño del mecanismo a desarro-llar. Por ejemplo, un mecanismo que garantice la privacidad delsoftware puede ser efectivo contra un ataque estático mientrasel software esté almacenado en disco, no siendo así contra unataque dinámico con el software ejecutándose en memoria.

A continuación se describen con más detalles cada uno de estosaspectos.

2.2 atributos de seguridad

La seguridad de la información se basa fundamentalmente en garanti-zar los atributos de privacidad, integridad y disponibilidad de los da-


tos durante su transmisión, procesamiento o almacenamiento (Stamp,2011).

En el contexto de la protección de software, la seguridad se “ga-rantiza”1 mediante la privacidad, la integridad y la disponibilidaddel software y los datos manejados por este, mientras se encuentraalmacenado en un soporte físico o es ejecutado en memoria.

2.2.1 Privacidad

La privacidad, conocida también como confidencialidad o secreto, esel atributo o servicio que permite mantener oculto el contenido de lainformación ante personas no autorizadas (Menezes et al., 1996). Exis-ten numerosos enfoques para proporcionar confidencialidad, que vandesde la protección física, hasta algoritmos matemáticos que hacenininteligible la información a interpretar.

En la protección de software, la privacidad está referida a manteneroculto la estructura y el funcionamiento, así como los datos maneja-dos por el software ante un atacante. De garantizarse, el atacante tieneque resignarse a realizar un análisis de caja negra, observando las en-tradas y salidas para inferir el funcionamiento interno del software.

2.2.2 Integridad

La integridad es el atributo o servicio que se ocupa de la alteraciónno autorizada de la información. Para asegurar la integridad de lainformación, es necesario detectar su manipulación por partes no au-torizadas. La manipulación de la información incluye la inserción,eliminación o sustitución de la misma (Menezes et al., 1996).

En la protección de software, la integridad está referida a la detec-ción de la manipulación no autorizada del código o los datos del soft-ware por un atacante, ya sea de forma estática o dinámica. El atacantepuede realizar modificaciones al software sin realizar un análisis pre-vio del funcionamiento del mismo. Estas modificaciones serán pocoobjetivas y la probabilidad de éxito del ataque será muy baja. Por este

1 En el contexto de la protección de software, la seguridad no puede ser garantizadapor tiempo indefinido y, al final, el atacante logrará violentarlo con más o menosesfuerzo.

2.2 atributos de seguridad 19

motivo, inicialmente se realiza un ataque contra la privacidad, antesde proceder con un ataque contra la integridad.

La integridad puede formar parte de la autenticación del origen delos datos. Si la información ha sido manipulada, entonces la fuenteque la ha emitido ha cambiado, por lo que no se considera auténtica.En la protección de software, la autenticidad puede verse asociadacon las marcas de agua frágiles (Zhu et al., 2005), que le permitena un usuario legítimo comprobar si el software es auténtico, o sea,que lo ha adquirido del fabricante auténtico y no ha sido sometido aningún ataque malicioso.

2.2.3 Disponibilidad

La disponibilidad se refiere a la capacidad de utilizar con eficacia lainformación o recurso deseado. La disponibilidad es importante enla seguridad pues un ataque deliberado puede negar el acceso a losdatos o servicios, haciéndolos inaccesibles (Stamp, 2011).

En la protección de software, es necesario tener en cuenta este atri-buto acorde a la legitimidad del usuario que haga uso del mismo.

De cara a un usuario ilegítimo, el mecanismo de protección debeser lo suficientemente robusto para contener un ataque, impidiendoque el software esté disponible el menor tiempo posible. Por ejem-plo, un mecanismo de protección debe resistir al menos, un tiempoprudencial entre una actualización y otra del mismo software, de es-ta forma el usuario ilegítimo no dispondrá nunca de un productoactualizado2.

Por otra parte, para un usuario legítimo, el mecanismo de protec-ción no debe producir un impacto apreciable sobre el rendimientodel software, afectando su desempeño o funcionalidad. Desafortuna-damente, la seguridad y el rendimiento son inversamente proporcio-nales, por lo que se hace necesario llegar a un consenso sobre losniveles de protección y rendimiento a alcanzar en el diseño de unmecanismo de protección.

2 Suponga que un usuario ilegítimo ha adquirido un software de forma ilegal. Poste-riormente se publica una corrección (update) de un error (bug) de la implementacióndel software que genera resultados erróneos. El usuario ilegítimo se verá imposibi-litado de actualizar su software pirateado y por tanto seguirá sujeto a ese tipo deerrores en los resultados.


2.3 modelo de amenazas

Aucsmith (1996) y A. Main (2003) enmarcan los ataques contra elsoftware en tres categorías o modelos de amenazas, basados funda-mentalmente en el origen de la amenaza y el privilegio que poseeel atacante sobre el sistema donde se ejecuta el software a violentar.Estos son: de red, interno y local.

Los ataques bajo el modelo de amenaza de red e interno, puedenser contenidos con adecuados mecanismos de autenticación y auto-rización, ya sea de forma local o remota, siempre y cuando se man-tengan las aplicaciones y el ambiente de ejecución (sistema operativo)libres de vulnerabilidades. Sin embargo, aún no se cuenta con un me-canismo eficaz que permita contener un ataque por tiempo indeter-minado bajo el modelo de amenaza local, constituyendo un problemaabierto de investigación. Al respecto, las actuales propuestas se basanen brindar una solución temporal al problema, para un contexto de-terminado (Tsaur, 2012).

El modelo de amenaza local no sólo tiene incidencia en la pirateríade software, sino que también afecta a otras áreas tal y como se indicóen el capítulo anterior. En sentido general, se ve afectado cualquierambiente de procesamiento al cual el atacante tenga total acceso ycontrol por disponer de poca o ninguna seguridad física3.

2.3.1 Red

Bajo este modelo, las amenazas sobre el software se originan fuera delambiente donde este se ejecuta. El ambiente se considera seguro (trus-ted host) e inaccesible para un atacante, pues la seguridad se garantizamediante adecuados controles de autenticación y autorización, tantofísicos como lógicos, y el atacante no cuenta con privilegios que lepermita acceder al mismo. Los ataques son llevados a cabo de for-ma remota a través de una red externa, mediante la explotación depotenciales vulnerabilidades presentes en el software.

3 El procesador criptográfico IBM 4758, a diferencia de los procesadores convencio-nales, presenta un conjunto de protecciones físicas que lo hacen más resistente amanipulación.

http://www-03.ibm.com/security/cryptocards/pcicc/overview.shtml

2.4 ataque 21

2.3.2 Interno

En este modelo, las amenazas se originan desde una red local o des-de el mismo ambiente donde es ejecutado el software, pero el atacan-te cuenta con mínimos privilegios en el sistema, por lo que aún seconsidera confiable. El ataque más común consiste en lograr escalarprivilegios en el sistema por alguna vulnerabilidad del mismo.

2.3.3 Local

Bajo este modelo, los ataques se realizan de forma local en la propiamáquina donde es ejecutado el software.

Dada la arquitectura insegura de los microprocesadores actuales, elambiente de ejecución del software se considera no confiable (untrus-ted host), pues el atacante cuenta con suficientes privilegios y herra-mientas para llevar a cabo el análisis y modificación del software deforma local. De esta forma, los atributos de privacidad e integridaddel software atacado se ven comprometidos.

2.4 ataque

Bajo un modelo de amenaza local, en el cual el ambiente de ejecu-ción es no confiable y el atacante tiene pleno acceso a los recursos desoftware y hardware, un software puede ser objeto de un ataque de-liberado mediante un proceso de ingeniería inversa de software (verfigura 4).

El proceso de ingeniería inversa es controlado por un atacante, em-pleando para ello un conjunto de herramientas y técnicas, que le per-miten inspeccionar y modificar la estructura y el comportamiento deun software, obteniendo como resultado un software pirateado.

El ataque mediante ingeniería inversa, está compuesto fundamen-talmente por tres subprocesos; (1) Inspección, (2) Manipulación y (3)Automatización, los cuales son descritos a lo largo de las siguientessecciones.

Las propuestas de mecanismos de protección para evitar la pirate-ría de software en un modelo de amenaza local, deben estar dirigidosa dificultar o retardar cada una de estos tres procesos.


<<goal>>

Piratear software

<<informatics>>

Software

Ingeniería inversa

Automatización

Inspección

Manipulación

<<information>>

Datos de inspección

<<supply>><<informatics>>

Software

<<people>>

Atacante

<<control>> <<achieve>>

<<information>>

Datos de manipulación

<<physical>>

Herramientas

<<supply>> <<supply>>

<<information>>

Casos de prueba

<<abstract>>

Técnicas

<<supply>>

Figura 4 Proceso de ingeniería inversa aplicado en la piratería de software.

2.4.1 Inspección

El objetivo de este proceso es la obtención de la mayor cantidad deinformación que le permita al atacante detallar, tanto la estructuracomo el comportamiento interno del software. Durante este proceso,el atacante adopta una posición pasiva, dado que se limita a analizarel software, viéndose comprometida la privacidad del mismo.

Como resultado de este proceso, se obtiene un conjunto de datosasociados a la inspección, por ejemplo las especificaciones de un al-goritmo con derechos de autor contenido en el software que permi-tan su posterior re-implementación en el proceso de automatización.Otro ejemplo es la obtención de las especificaciones del algoritmode validación de licencias de un software que permiten la posteriorimplementación de un generador de claves (keygen).

El software puede ser inspeccionado o analizado de forma estáticacuando se encuentra en el medio de almacenamiento, o de formadinámica cuando es ejecutado en memoria, complementándose ambostipos de inspección en un modelo híbrido (Madou et al., 2005) (verfigura 5).

2.4 ataque 23

<<goal>>

Obtener información

Inspección

Integrar datos de inspección

Análisis estático

Integrar datos estáticos

Desensamblar

Decompilar

Análisis dinámico

Integrar datos dinámicos

Depurar

Emular

Perfilar

Trazar

<<informatics>>

Software

<<information>>


<<information>>

Datos de análisis estático

<<information>>

Datos de análisis dinámico

<<archieve>>

<<information>>

Casos de prueba

<<supply>>

Figura 5 Proceso de inspección.

Los mecanismos de protección destinados a retardar el proceso deanálisis, deben ser resistentes a análisis estáticos y dinámicos al mis-mo tiempo.

Análisis estático

El análisis estático consiste en inspeccionar el software y los datos ma-nejados por éste mientras se encuentra en el medio de almacenamien-to. Bajo este análisis solo se obtiene información estática del software,mediante la inspección del código del programa tras un proceso dedesensamblado o decompilación.

Es necesario destacar que mediante este tipo de análisis, se obtienemuy poca información sobre el comportamiento del software.


Análisis dinámico

El análisis dinámico se realiza sobre el código y los datos durante laejecución en memoria. De esta forma, se obtiene información dinámi-ca (no persistente) tales como el flujo de control y de datos, valoresde los registros, la pila, zonas de memoria, etc.

Algunos de los procesos que permiten obtener esta informaciónson la depuración, la emulación (emulation), el perfilado (profiling) yel trazado (tracing) de un software.

Si bien el ataque dinámico suele ser más robusto que el análisisestático, puede tomar más tiempo, ser más complejo y requerir mayorconocimiento por parte del atacante.

2.4.2 Manipulación

En el proceso de manipulación, el objetivo del atacante es la modi-ficación deliberada del comportamiento del software acorde a susnecesidades, por lo que se atenta directamente contra la integridaddel mismo. El resultado de este proceso consiste en un conjunto deespecificaciones que permiten la posterior modificación del software.

Para llevar a cabo este proceso, el atacante se basa en toda la infor-mación obtenida durante el proceso de inspección, dado que necesitacomprender el funcionamiento interno del software antes de modifi-carlo (ver figura 6).

El proceso de manipulación está constituido por tres subprocesos:(1) Localización, (2) Manipulación y (3) Comprobación. Esta caracteri-zación fue propuesta por Anckaert et al. (2007) y Collberg and Nagra(2009) tras establecer una analogía del proceso de manipulación conel proceso de depuración de un software.

Este proceso es iterativo, pues el atacante inicialmente debe locali-zar el origen del comportamiento no deseado que quiere modificar,manipularlo y por último comprobar que los cambios realizados sonadecuados para obtener el comportamiento deseado. Dado que el ata-cante puede errar en la localización o manipulación del código aso-ciado al comportamiento no deseado, el proceso tiene que repetirsenuevamente una y otra vez hasta lograrlo.

2.4 ataque 25

Manipulación

Comprobar

<<goal>>

Obtener información

<<informatics>>

Software

<<information>>


<<supply>>

<<information>>


<<information>>

Datos de localización

Análisis de caja negra

Análisis de caja blanca

Manipular

Eliminar

Insertar

Sustituir

Localizar

Reproducir comportamiento

Refinar localización

<<supply>>

<<archieve>>

<<information>>

Casos de prueba

<<supply>>

<<information>>


Figura 6 Proceso de manipulación.

Los mecanismos de protección deben ser capaces de obstaculizar alatacante en la ejecución de cada una de estos tres procesos. Por ejem-plo, se puede hacer más lento el proceso de localización y comproba-ción con un comportamiento no-determinista del software mediantela replicación de diferentes caminos de ejecución, seleccionándolasde forma aleatoria en tiempo de ejecución (Anckaert et al., 2007). Porotra parte, el proceso de manipulación puede obstaculizarse, distribu-yendo diferentes puntos de control de integridad por todo el softwa-re, haciéndolos interdependientes entre sí, de forma tal que un solocambio local no sea suficiente para desactivar todo el mecanismo deprotección (Horne et al., 2002).

Localización

El atacante inicialmente tiene que localizar el origen del comporta-miento no deseado, apoyándose en los datos obtenidos del procesode inspección.

La primera actividad que realiza el atacante es la reproducción delcomportamiento no deseado. En otras palabras, el atacante tiene que


ser capaz de conducir el software al estado en que muestre el com-portamiento no deseado, identificando el conjunto de variables deentradas (caso de prueba), así como el control de flujo del softwareque la conduce a dicho estado.

Retomando el ejemplo de la violación del mecanismo de control delicencias de un software. En este caso, el comportamiento no deseadoes la manifestación de un error tras la verificación de una licenciainválida proporcionada por el atacante (vea Eilam, 2005, cap. 11).

Una vez que el atacante ha sido capaz de reproducir el comporta-miento no deseado, pasa a una actividad en la cual trata de localizarel origen de dicho comportamiento. A partir de la manifestación delcomportamiento no deseado, el atacante puede retroceder hasta el ori-gen del mismo por el grafo de control de flujo del software medianteuna depuración inversa. Este proceso es cíclico, pues el atacante varefinando la búsqueda hasta donde él cree que se encuentra el origenque genera el comportamiento no deseado.

El atacante puede valerse de técnicas más complejas para localizarel objetivo de interés, a continuación se relacionan algunas.

• Análisis diferencial de software. Consiste en comparar dos omás versiones de un mismo software para identificar las partesque han sido modificadas de una versión a otra. Por ejemplo,un atacante puede descubrir la posición de una marca de aguade licencia (licensing watermark) (Nagra et al., 2002) a partir decomparar dos software destinadas a usuarios diferentes. Dadoque los datos de los usuarios finales son diferentes, la compara-ción de los dos software revelara la posición de la marca por serel único elemento distintivo entre los dos software. Para evitareste tipo de ataque se requiere aplicar técnicas de diversidad decódigo (Anckaert et al., 2007; Schrittwieser and Katzenbeisser,2011) a cada uno de los software a distribuir, de forma tal quesean totalmente diferentes y no solo una parte de estos.

• Ataque por colusión. Un ataque por colusión implica múltiplesatacantes compartiendo información del proceso de análisis deun mismo software. Puede combinarse con el ataque diferencialpara comparar dos trazas de ejecución diferentes de un mismosoftware.

2.4 ataque 27

• Ataque por repetición. Consiste en capturar el estado de todo elsoftware durante una ejecución y después analizarlo de formaestática.

• Ataque de canal lateral. Consiste en obtener información delmedio físico donde es ejecutado el software, por ejemplo el por-centaje de utilización de la CPU o el consumo de potencia.

Manipulación

Una vez que el atacante cree haber localizado el origen del compor-tamiento no deseado, procede a eliminar, insertar o sustituir adecua-damente parte del código o los datos para lograr el comportamientodeseado.

Generalmente, las transformaciones realizadas alteran el flujo deejecución, para que, ante una misma entrada de datos, el resultadosea diferente respecto al software sin manipular. Por ejemplo, si elatacante logra modificar adecuadamente el mecanismo de control delicencias, el software aceptará como válida una licencia ilegítima queantes de la modificación la daba como inválida.

Las manipulaciones pueden ser dinámicas o estáticas:

• Manipulación Dinámica. Tiene un tiempo de vida corto, limita-do solamente al tiempo que dure la ejecución del software. Estopermite modificar temporalmente el código o los datos dinámi-cos cargados en memoria durante la ejecución.

• Manipulación Estática. Tiene un tiempo de vida largo, lo quegarantiza que los cambios realizados sobre el código o los datossean persistentes y se reflejen en memoria cada vez que se eje-cute el software. De esta forma, la imagen del software en discoserá la misma que se ejecuta en memoria, salvo los datos que segeneren de forma dinámica.

La manipulación dinámica se emplea profusamente durante el pro-ceso de modificación y prueba hasta tanto el atacante tenga certezade que ha sido correcta, momento en el cual procede a realizar unamanipulación estática.


Comprobación

Para tener la certeza que los cambios realizados han sido satisfacto-rios, el atacante pasa a una fase de verificación, realizando dos prue-bas distintas, una de caja negra (prueba funcional) y posteriormenteuna de caja blanca (prueba estructural). En cualquiera de los dos ti-pos de prueba, el atacante debe llevar el software al estado en el quemuestra si se ha eliminado o no el comportamiento no deseado.

En la prueba de caja negra, el atacante analiza el software como sifuese un oráculo, observando solamente la correspondencia entre lasentradas y salidas. Si la manipulación realizada ha sido la correcta,para un conjunto de datos de entrada, obtendrá un conjunto de datosde salida deseado. En el ejemplo, una prueba de caja negra consisteen proporcionarle al software una licencia inválida y como respuestase debe obtener un mensaje indicando la aceptación de dicha licenciacomo si fuese legítima.

Si tras esta prueba, no se manifiesta una adecuada relación entre lasentradas y las salidas acorde a las necesidades del atacante, entoncesejecuta en una prueba de caja blanca, con el fin de localizar la causadel comportamiento erróneo. Pueden existir dos posibilidades: que lamodificación inicial no se haya implementado correctamente o que lalocalización no haya sido precisa. En el primer caso se deberá repetirel proceso de manipulación, y en el segundo el de localización.

Si, por el contrario, la manipulación del software ha sido la correcta,se genera la información necesaria para la posterior automatizaciónde dicha manipulación.

2.4.3 Automatización

El proceso de automatización tiene como objetivo, en primer lugar,simplificar el ataque por parte de un usuario ilegítimo que no tengaconocimiento alguno sobre técnicas de ingeniería inversa, y en segun-do lugar, permitir una propagación masiva del ataque (ver figura 7).

El proceso de automatización cuenta con dos actividades. En laprimera actividad se automatiza los resultados del proceso de ins-pección mediante la implementación de un generador de claves o lare-implementación de un algoritmo de propiedad intelectual conteni-do en el software para su libre distribución.

2.5 conclusiones 29

<<information>>


<<information>>


Automatización

Automatizar inspección

Automatizar manipulación

<<goal>>

Automatizar ataque

<<achieve>>

<<informatics>>

Software

Figura 7 Proceso de automatización.

En la segunda actividad se automatiza el resultado del procesode modificación, generalmente a través de un parche que desactivadirectamente el mecanismo de control de licencias de un softwareespecífico.

2.5 conclusiones

En el presente capítulo se abordaron las principales definiciones quesustentan las técnicas de protección de software en la actualidad.

La piratería de software se debe, desde el punto de vista tecnoló-gico, al modelo de amenaza local en el que el ambiente de ejecuciónse considera no confiable (untrusted host threat model) debido a la ar-quitectura insegura de los procesadores actuales. De esta forma, seven comprometidos los atributos de privacidad e integridad de loscomponentes de software sometidos a un ataque.

Como resultado del estudio realizado, se identificaron las princi-pales formas de piratería de software. La piratería de usuario finalno implica una modificación de la componente de software, sino elincumplimiento del acuerdo de usuario final aceptado por el cliente.La piratería relacionada con software manipulado y parches alteranla integridad y la privacidad del software atacado. La generación delicencias no válidas y las copias de propiedad intelectual afecta el atri-buto de la privacidad de la componente. Consecuentemente, el diseñode cada mecanismo de protección aspira a garantizar un subconjuntoespecífico de atributos de seguridad.


Tomando como precedente el modelo de amenaza local, se carac-terizaron los tres subprocesos principales del proceso de ingenieríainversa que puede llevar a cabo un atacante sobre una componenteejecutable: inspección, manipulación y automatización.

Durante el proceso de inspección se obtiene toda la informaciónnecesaria para comprender el funcionamiento de la componente eje-cutable, por lo que se considera un ataque pasivo. Puede realizarse deforma estática en un medio de almacenamiento persistente o formadinámica mientras la componente es ejecutada en memoria.

La manipulación, por el contrario se centra en conseguir la elimi-nación de un comportamiento no deseado, por lo que se consideraun ataque activo. Para ello se emplea la información obtenida duran-te el análisis en un proceso cíclico de localización, manipulación ycomprobación (locate-tamper-test).

1. Localización. El objetivo es localizar el comportamiento no desea-do, empleando para ello diferentes técnicas: depuración inversa,análisis diferencial de software, ataque por colusión, entre otros.

2. Manipulación. El objetivo es eliminar el comportamiento nodeseado. Tras una localización efectiva, se puede realizar unamanipulación deliberada, ya sea insertando, modificando o adi-cionando información de forma consciente.

3. Comprobación: El objetivo es comprobar que las manipulacio-nes realizadas hayan sido exitosas. Se realiza mediante pruebasestructurales (caja blanca) y funcionales (caja negra) de los com-ponentes de software comprometidos. En ambos casos el ata-cante deberá disponer de un conjunto de casos de prueba, quele garantice una alta cobertura de código.

Las técnicas de protección a emplear deben tener en cuenta la natu-raleza de estos ataques para retardarlos tanto como sea posible. Cadatécnica de forma independiente puede estar destinada a retardar unproceso particular del ataque, por lo que una protección integral sealcanza combinando diferentes técnicas de protección. Los elementosantes mencionados constituyen las bases para el diseño de un meca-nismo de protección específico.

3E S TA D O A C T U A L D E L A S T É C N I C A S D EA U T O - V E R I F I C A C I Ó N D E I N T E G R I D A D

Hasta el momento se ha podido apreciar que la piratería de softwarees un problema latente, debido fundamentalmente a la inseguridadde los ambientes de ejecución. Esto justifica el empleo de técnicas deprotección de software que garanticen, en cierta medida, los atributosde seguridad deseables de un software a comercializar. Al respecto sehan propuesto diversas técnicas de protección que aseguran en algúngrado la protección del software.

En este capítulo se expone un estudio del estado del arte de latécnica de auto-verificación de integridad. Dada la relativa novedadde la misma, es fundamental una revisión de las propuestas actualespara identificar los elementos comunes que permitan caracterizarlasadecuadamente y evaluar su seguridad.

En la Sección 3.1 se realiza una propuesta de clasificación, a partirde la cual se agrupan las propuestas de diferentes autores según elcriterio de clasificación. Dentro de esta clasificación, se encuentran loscomponentes que conforman una red de auto-verificación. Una revi-sión de los mismos puede ser vista en las Secciones 3.2 y 3.3. Por otraparte, en la Sección 3.4 se describen las propuestas que tienden a in-tegrar elementos de privacidad e integridad en una misma solución,destacando los mecanismos de protección basados en comportamien-tos aleatorios o no-deterministas. Seguidamente, en la Sección 3.5 seexponen algunas propuestas realizadas por diversos autores para eva-luar el nivel de seguridad de los sistemas resistentes a manipulación.Finalmente, se dan las conclusiones del capítulo en la Sección 3.6.

31

32 estado actual de las téc . de auto-verificación de integridad

3.1 auto-verificación de integridad

La técnica de Auto-verificación de Integridad (AVI), ha tenido undesarrollo creciente en las últimas dos décadas dada la imperiosa ne-cesidad de garantizar la integridad de las aplicaciones en ambientesinseguros de ejecución.

Los mecanismos de auto-verificación de integridad (integrity self-checking) (Horne et al., 2002), también referidos en la literatura comosoftware resistente a manipulación (software tamper resistant) (Aucs-mith, 1996; Ghosh et al., 2010; Tan et al., 2007; Tsang et al., 2011)o a prueba de manipulación (software tamper-proofing) (Collberg andThomborson, 2002), están dirigidos a aumentar la resistencia ante ata-ques por modificación, ya sean estáticos o dinámicos. Se emplea eltérmino auto-verificación porque el software es el encargado de pro-tegerse a sí mismo, a través de los componentes de control que lefueron adicionados como parte del mecanismo de protección.

En la presente investigación, sólo se contemplarán los mecanismosresistentes a manipulación basados únicamente en software, específi-camente los que realizan controles de integridad de forma directa. Esnecesario realizar esta distinción, porque existen otros mecanismosque ofrecen resistencia a manipulación y no verifican directamente laintegridad del software, por ejemplo, los basados en diversidad decódigo (Anckaert et al., 2007; Schrittwieser and Katzenbeisser, 2011),cifrado de caja blanca (white-box cryptography) (Michiels, 2010) y auto-modificación de código (Cai et al., 2007).

De forma general, la técnica AVI puede ser empleada para garanti-zar, con mayor o menor nivel, la integridad de las aplicaciones en unambiente inseguro de ejecución. Dicha técnica está conformada pordos componentes funcionales (Tan et al., 2007):

1. Componente de detección de modificación. Componente encar-gado de detectar modificaciones no autorizadas sobre el softwa-re que cambien deliberadamente su comportamiento.

2. Componente de respuesta ante modificación. Componente en-cargado de brindar una respuesta ante una modificación detec-tada.

3.1 auto-verificación de integridad 33

El funcionamiento de estos dos componentes varía de una propues-ta a otra, dependiendo de los detalles específicos considerados porcada autor. Con el objetivo de agrupar lógicamente las propuestasrealizadas por diferentes autores, se establece una clasificación de es-tos dos componentes de acuerdo a diferentes criterios (ver figura 8).

Auto-verificación de integridad

Componente de detección

Componente de respuesta

Objeto de verificación

Procedimiento de verificación

Ubicación

Tipo

Figura 8 Clasificación de los mecanismos de auto-verificación de integridad.

El componente de detección de modificación está dirigido a detectarmodificaciones sobre un objeto de verificación mediante un procedimien-to de verificación. El componente de respuesta ante modificación puedevariar atendiendo a su ubicación o dependiendo del tipo de respuestaque se emita. En los próximos epígrafes se relacionarán las propues-tas de diversos autores atendiendo a esta clasificación.

De forma general se expone la necesidad de combinar el mecanis-mo de control de integridad con técnicas que garanticen privacidad(Aucsmith, 1996) con el objetivo de aumentar la resistencia a modifi-cación, tanto del software, como del propio mecanismo de protección.

Es deseable que los componentes de detección y de respuesta esténseparados espacial y temporalmente en el grafo de control de flujodel software (Tan et al., 2007), con el objetivo de que el descubrimien-to de un componente por el atacante no conlleve inmediatamente aldescubrimiento del otro componente. En un análisis práctico realiza-do por Piazzalunga et al. (2007); Salvaneschi and Piazzalunga (2008)en la violación de protecciones basadas en hardware complementa-rios (dongle), se reconoce que cuando la verificación y la respuesta(referida como mensaje de error) se encuentran separadas en el espa-


cio, se requiere de un mayor esfuerzo para hacer efectivo el ataquepor cada nodo de verificación que invoca una sola respuesta.

De existir un solo componente de detección y respuesta en todo elsoftware, la seguridad estaría centralizada, constituyendo una debili-dad pues el atacante solo tendría que localizar y desactivar un sólopunto de control de integridad. Para evitar esta situación y lograr unamayor robustez ante ataques, varios autores proponen conformar unared de auto-verificación de integridad.

La red de auto-verificación estaría constituida por varios nodos(componentes de detección y respuesta) distribuidos por todo el soft-ware verificándose entre sí. De esta forma, existe una verificación dis-tribuida, forzando al atacante a desactivar cada uno de los nodos.

En este capítulo se analizarán las propuestas más significativas dela técnica AVI, haciendo énfasis en los componentes de detección demodificación y respuestas ante modificación, valorando sus ventajase inconvenientes. Acto seguido se analizan las diversas propuestasque incorporan elementos de privacidad como complemento al con-trol de integridad. Por último se hace un análisis de las métricas deseguridad existentes que pueden ser empleadas en la evaluación dela seguridad de este tipo de mecanismo.

3.2 componente de detección de modificación

El mecanismo de detección es el encargado de detectar cualquier mo-dificación no autorizada sobre un objeto de verificación pertenecien-te al software mediante un procedimiento de verificación (Tan et al.,2007) (figura 9).

El objeto de verificación puede ser el código (instrucciones) (Horneet al., 2002) o los datos (Jacob et al., 2007), dado que ambos pueden serel objetivo de una modificación deliberada durante un ataque. Unavez que se ha obtenido la información necesaria sobre el objeto deverificación, se procede a chequear su integridad en busca de algunamodificación. El procedimiento para verificar la integridad puede es-tar basada en uso (Cappaert et al., 2008; Lee et al., 2005) o afirmación(Chang and Atallah, 2002; Horne et al., 2002).

3.2 componente de detección de modificación 35

Figura 9 Clasificación del mecanismo de detección.

3.2.1 Objeto de la verificación

Hasta el momento se han identificado dos vías para verificar la in-tegridad de un software. Alrededor de éstas giran la mayoría de losalgoritmos propuestos.

La primera vía consiste en chequear directamente la integridad delcódigo durante la ejecución en memoria. Se considera una verifica-ción sintáctica del software, pues solo se tiene en cuenta la correcciónformal del código (sintaxis) y no el comportamiento del software (flu-jo de control) a partir del estado de los datos.

La segunda vía verifica que el estado de los datos en memoria seael correcto en cada momento. Se considera una verificación de la se-mántica del software pues no solo se asegura la integridad del código,sino también el flujo de ejecución de éste en dependencia del estadode los datos.

Verificación de código

La verificación de código consiste en determinar que las instruccio-nes de código sean las correctas y que no hayan sido modificadasdeliberadamente en el medio de almacenamiento o durante la eje-cución del software. Esta fue la primera técnica que se utilizó parala auto-verificación de integridad por su eficiencia y facilidad en laimplementación.

Es necesario destacar que presenta dos deficiencias fundamentalesque la debilitan en cierta forma. La primera es que las aplicaciones


usualmente no realizan lecturas a su propia sección de código, lo querevelaría la presencia del mecanismo de verificación mediante unasencillo análisis dinámico. La segunda deficiencia es que este métodono es capaz de detectar cambios realizados en los datos, pudiéndosealterar el funcionamiento del software, sin que este fuera advertido.Por ejemplo, después de una comparación, el estado de las banderasde un proceso en memoria puede ser manipulado para invertir ladirección de un salto condicional, alterando el flujo de control (Eilam,2005).

Varias son las propuestas basadas en la verificación de código. Hor-ne et al. (2002) propone el uso de comprobadores que brindan la po-sibilidad de proteger todo el código del ejecutable sin importar sutamaño, detectando los ataques tan pronto se hayan efectuado. El con-junto de estos comprobadores conforma una red de auto-verificaciónredundante. Jin et al. (2005) proponen un mecanismo en el cual, losresúmenes calculados que resultan de realizar las lecturas del código,son utilizados en un mecanismo que se le denomina “evolución declave”.

Trabajos que relacionan el cifrado de código y la auto-verificaciónde integridad (integrity-based encryption) pueden ser vistos en (Cap-paert et al., 2008; Lee et al., 2005). El objetivo de estas propuestases garantizar la privacidad e integridad del software protegido. Laprivacidad se logra al cifrar las partes del código que se desea pro-teger. Para descifrar dichas partes, el propio software en tiempo deejecución realiza lecturas a otras partes del código, empleando dichainformación como claves para el descifrado. Si las zonas que sirvende clave son manipuladas deliberadamente, entonces el descifrado noserá el correcto, impidiendo la correcta ejecución del software.

Además de los inconvenientes mencionados al inicio del epígrafe,se suma la vulnerabilidad puesta de manifiesto mediante el ataquerealizado por van Oorschot et al. (2005); Wurster et al. (2005) queafecta a todos los algoritmos de auto-verificación de integridad basa-dos en chequeos de código. El ataque se basa en las características delos procesadores von Neumann, en los cuales la memoria es compar-tida para almacenar tanto los datos, como las instrucciones. El ataqueconsiste en realizar una modificación del sistema operativo y haceruna réplica de las páginas de memoria del programa original y mo-


dificar la copia hecha. Durante el ataque, el código modificado va aredirigir las lecturas, para el cálculo del resumen, hacia las páginas dememoria donde se encuentra el programa sin modificar, por lo queno se van a detectar los cambios. Se trata de un procedimiento genéri-co, pues es independiente del tipo de mecanismo de auto-verificaciónde código que se utilice.

Un trabajo realizado por Giffin et al. (2005) expone una alternativapara burlar este tipo de ataque. Consiste básicamente en utilizar latradicional técnica de auto-verificación de integridad, combinándolacon la auto-modificación de código para detectar si el sistema opera-tivo ha sido modificado o no.

Rogers et al. (2007) en su esquema de protección mediante firmasdigitales, realiza lecturas del código para generar dichas firmas. Elautor destaca que los ataques mediante redirección de código son di-fíciles de evitar, plantea la posibilidad de generar el código de formadinámica en el momento de usarlo (semejante a la compilación “just-in-time” 1) cómo una vía para garantizar la privacidad del software.

Verificación de datos

Esta variante surge fundamentalmente para eliminar las deficienciasde la técnica anterior, lo que presupone un nivel superior de seguri-dad. En primer lugar se eliminan las lecturas directas del código yen segundo lugar se detectan los cambios realizados a los datos enmemoria.

La verificación de los datos no permite detectar cambios en el có-digo directamente, pero al chequear el flujo de control del softwarea través de los cambios que ocurren en los datos, puede inferir cam-bios en el mismo de forma indirecta. Se considera una verificación dela semántica del software pues, no solo se asegura indirectamente laintegridad del código, sino también el flujo de ejecución de este endependencia del estado de los datos.

Uno de los primeros mecanismos basados en esta técnica fue elplanteado por Chen et al. (2003) conocido como resumen disimula-do (Oblivious Hashing (OH)). El procedimiento consiste en calcular

1 Compilación just-in-time. Conocida como interpretación dinámica. En tiempo deejecución del programa, se convierte el código del programa en instrucciones nativasde la arquitectura usada, p. ej. el bytecode de Java en código nativo del procesador.


el resumen (hash) de la traza de ejecución de una porción de códi-go de interés, y posteriormente verificar su integridad. También sehan realizado implementaciones de OH en Java (Chen et al., 2007).Jacob et al. (2007) propone un método que permite complementar elOH para que pueda realizar verificaciones del código. Su mecanismono hace uso de la auto-modificación de código propuesta en (Giffinet al., 2005), para lograr protección contra el ataque de replicación depáginas propuesto en (van Oorschot et al., 2005; Wurster et al., 2005).

La principal desventaja del OH y sus derivados es que sólo pue-den ser aplicados a ciertos segmentos de código con característicasespecíficas, lo cual limita notablemente su aplicabilidad. Jakubowskiet al. (2007) propone una generalización del OH para aliviar esta limi-tación, pero a costa de producir un deterioro apreciable del tamañoy tiempo de ejecución del software. Los autores exponen dos pre-dicados de programas: Condiciones de Verificación Probabilística (Probabilistic Verification conditions (PVC)) y Aproximación de Aprendi-zaje de Fourier (Fourier-Learning Approximations (FLA)) para chequearla integridad de un software. PVC se basa en la transformación deun fragmento lineal del software (sin ciclos o saltos de control) enun conjunto de ecuaciones polinomiales. De cada conjunto de ecua-ciones, se calculan las “bases reducidas” (resumen), que eliminan lasvariables y ecuaciones redundantes que no contribuyen a la salida delfragmento. Estas bases dependen del código y son consistentes con lasemántica de entrada-salida del fragmento de software analizado, porlo que pueden ser utilizadas para verificar la integridad del mismo.De forma similar, en el método FLA, un fragmento de código es vistocomo una función que opera sobre las lecturas de las variables dentrodel fragmento. Este esquema trata estas funciones como una serie defunciones de componentes que mapean las variables de entrada enun solo bit. Una técnica de aprendizaje basada en Fourier convierteestas funciones en una tabla de coeficientes de Fourier. La transforma-da inversa puede usar esta tabla para aproximar la función original.Junto con los coeficientes, la transformada inversa puede emplearsepara verificar cada bit individual de la función objetivo.


3.2.2 Procedimiento de verificación

Una vez que se ha obtenido la información necesaria del objeto deverificación, lo que se conoce como firma de integridad, se procede arealizar su verificación en busca de alguna modificación. La verifica-ción puede estar basada en afirmación o uso.

Basadas en afirmación

El procedimiento de verificación basado en afirmación consiste en com-parar directamente la firma de integridad obtenida durante la eje-cución del software, con la misma firma precalculada antes de rea-lizar la distribución del software (Horne et al., 2002; Rogers et al.,2007). De existir inconsistencia en dicha comparación, se presupo-ne una modificación no autorizada del software. A continuación semuestra un sencillo ejemplo en el que se utiliza una función resumen(CalculateHash) como firma de integridad y una simple comparaciónpara realizar el procedimiento de verificación.

ActualHash = CalculateHash ();

if (ActualHash != OriginalHash) break;

Un ataque satisfactorio ante este tipo de verificación consiste eninvertir el signo de la comparación en el código del ejecutable en elmomento en que se hace la verificación (Eilam, 2005, cap. 11). Si seprocede a realizar una modificación en el software, esta pasará inad-vertida y la ejecución continuará de manera normal violentándose laprotección. Para que este procedimiento sea efectivo es imprescindi-ble proteger tanto la firma precalculada como el punto de compara-ción.

Existen dos posibles vías de solución para soslayar este inconve-niente. La primera es tratar de ofuscar la firma de integridad precal-culada con el objetivo de hacer difícil su localización y posterior mo-dificación (Horne et al., 2002). La segunda es protegerlos contra mo-dificación mediante la propia técnica AVI (Chang and Atallah, 2002).Para esto se necesitan redes circulares de verificación, sin embargo és-tas no pueden ser implementadas cuando se utilizan funciones hashlineales de un solo sentido. Este problema provoca la existencia denodos desprotegidos en la red, presentando por tanto una vulnerabi-lidad fácil de descubrir para un atacante. La mayoría de los autores


no tienen en cuenta esta circunstancia y solo unos pocos proponenuna alternativa.

Rogers et al. (2007) utiliza en su propuesta un esquema basado enfirmas digitales. Cada bloque de instrucciones de ejecución es firma-do de forma segura con un algoritmo criptográfico de firma. Durantela ejecución del programa, las firmas son calculadas nuevamente apartir del código que se encuentra en memoria y comparada con lasfirmas embebidas en el software. Si son diferentes se asume que haexistido una modificación del código. Por su parte Chen et al. (2003)propone dos alternativas en su técnica de resumen disimulado (obli-vious hashing). Su algoritmo va actualizando un resumen inicial a lolargo de un camino de ejecución determinado dentro del software.En determinados puntos realiza la verificación del resumen actuali-zado contra el resumen precalculado para detectar modificaciones.Sin embargo, no especifica si se brinda algún tipo de protección almismo. Como segunda variante, propone tener réplicas idénticas fun-cionalmente de un código a las cuales se les calcula el resumen porseparado y después se comparan entre sí, de esta forma no es necesa-rio almacenar el resumen precalculado, no obstante sigue existiendoun punto de verificación no deseable. El comportamiento es similara los sistemas tolerantes a fallos, que introducen redundancia en elcómputo y mediante un algoritmo de votación, determinan cuál es elvalor correcto. Tal es el caso de la propuesta realizada por Jakubowskiet al. (2009) que se basa en este principio.

Jacob et al. (2007), propone algo semejante a la comparación deréplicas de código de OH. En este caso la comparación no es entrelos resúmenes calculados a partir de la ejecución de segmentos decódigos equivalentes funcionalmente. En el mecanismo propuesto severifica la sintaxis de dos réplicas del mismo código entre sí. Una delas réplicas se ejecutaría y la otra solo se usa para verificar la inte-gridad, mediante la comparación de instrucciones. Todo este códigoestaría protegido mediante un mecanismo contra desensamblado quedenominan intercalado de código (code interleaving).

La variante en línea de Jin and Lotspiech (2003a,b); Jin et al. (2005,2007) consiste en realizar una evolución de una clave a partir de con-troles de integridad al código del software. Como variante, los autoresoptaron por enviar dicha clave hacia una entidad de confianza, en la


cual se compararía con la clave original resultante del programa sinmodificaciones. Con esto logran no tener que almacenar ningún resu-men precalculado y el punto de verificación está fuera del alcance delatacante.

En resumen, se identifican dos técnicas de verificación basada enafirmación. La primera es tener una firma de integridad precalculadacontra el cual realizar la comparación y tratar de protegerlo de algunaforma; ya sea por redes circulares de verificación o por ofuscación.La segunda, consiste en prescindir de la firma precalculada y realizarcomparaciones de firmas obtenidas por vías diferentes; por ejemplo apartir de replicas de códigos. En ambos casos se mantienen los puntosde verificación lo cual constituye una vulnerabilidad.

Basadas en uso

El procedimiento de verificación basado en uso consiste en emplearla firma de integridad para realizar alguna operación íntimamenteligada a la lógica de negocio de la aplicación. De esta forma, cualquiermodificación provocará un funcionamiento inesperado de la misma.En este sentido, algunos trabajos proponen emplear la firma comoclave para descifrar partes del código previamente cifradas o pararegular el flujo de ejecución del software.

Lee et al. (2005), Cappaert et al. (2008) y Li et al. (2009a) proponende forma independiente algoritmos semejantes, basados en métodosde cifrado de aplicaciones y auto-verificación de integridad, comple-mentándolos entre sí. El principio básico de funcionamiento es elmismo para estas propuestas. La idea consiste en mantener cifradobloques de código del software y descifrarlos solo para su ejecución,usando como clave el código de otra parte del software.

Otra variante de verificación basada en uso fue propuesta por Jinand Lotspiech (2003a,b); Jin et al. (2005, 2007). El autor propone unatécnica denominada de detección de modificación basada en el flujode ejecución (branch based tamper detection) en la cual, la clave calcula-da es usada para regular el flujo de control del software.


3.3 componente de respuesta ante modificación

El componente que emite una respuesta como consecuencia de detec-tar una modificación no deseada puede clasificarse en función de suubicación y en función del tipo de respuesta que implementa (figura10).


Ubicación

Tipo

Local

Remota

Rendimiento

Funcionamiento

Tolerancia

Figura 10 Clasificación del mecanismo de respuesta.

Las respuestas, dependiendo de la ubicación donde son ejecutadas,pueden ser locales o remotas.

El tipo de respuesta local puede ser un evento inusual, que lleve alsoftware a un estado inestable mediante una degradación del funcio-namiento o del rendimiento de ejecución (Tan et al., 2007), o de formacontraria, establecer una tolerancia al ataque, restableciendo el softwa-re a su estado inicial antes de la modificación (Chang and Atallah,2002; Jakubowski et al., 2009).

En el caso de las respuestas remotas, se puede informar a una auto-ridad apropiada de la detección de una modificación (Jin et al., 2007).

3.3 componente de respuesta ante modificación 43

3.3.1 Ubicación de la respuesta

Locales

Las respuestas locales son emitidas en el mismo ordenador donde seejecuta el software, por lo que su efecto inmediato es percibido por elatacante (Oishi and Matsumoto, 2011; Tan et al., 2007).

Este tipo de respuesta se emplea fundamentalmente en aplicacio-nes que carecen de conectividad y toda la lógica de negocio del soft-ware se encuentra centralizada en un mismo ordenador (a diferenciade las aplicaciones cliente-servidor).

El principal inconveniente que presenta este tipo de respuesta esque la fábrica de software que desarrolló el producto, no tiene notifi-cación alguna sobre el ataque. Esto impide que pueda tomar algunaacción inmediata al respecto. La única vía que tiene la fábrica de soft-ware para percatarse del ataque, es que el atacante distribuya porinternet el software ya pirateado.

Dado que el ambiente de ejecución se considera hostil, las respues-tas deben estar en correspondencia con dicho ambiente (ver epígrafe3.3.2).

Remotas

En el caso de las respuestas remotas, el mecanismo de protección en-vía una alerta a una entidad de confianza mediante una conexión dered, indicando la violación de la integridad del software (Jin et al.,2005; Wyseur, 2010). Una vez que la entidad de confianza ha deter-minado que un software ha sido atacado, tomará una acción comorespuesta, que bien puede ser de tipo legal (si obtiene la informa-ción sobre el atacante) o tecnológica (suspensión de actualizaciones,servicios, etc.)

El principal inconveniente de este tipo de respuestas es que nece-sitan de una conexión periódica con la entidad de confianza, lo quehace que sean menos empleadas que las respuestas locales. Un sim-ple ataque consiste en modificar el software protegido e impedir unaconexión con la entidad de confianza. De esta forma, la modificaciónrealizada será detectada, pero la respuesta en consecuencia no seráefectiva, por lo que el mecanismo de protección queda desactivado.


Se recomienda emplear este tipo de respuestas en aplicaciones ba-sadas en un modelo de negocio en el cual, las aplicaciones clientesrequieran mantener algún tipo de relación con un proveedor de ser-vicios que sea confiable. Un ejemplo de este tipo de aplicaciones sonlas basadas en un modelo cliente-servidor o en una arquitectura orien-tada a servicios, que requieran de una conectividad periódica o cons-tante para su funcionamiento, pues parte de la lógica de negocio seencuentra en un servidor confiable.

De ser posible, es deseable complementarla con respuestas locales,en un sistema híbrido, para obtener mejores resultados de seguridad.

3.3.2 Tipos de respuesta

Los tipos de respuestas que a continuación se relacionan, son emplea-dos fundamentalmente en respuestas locales y no son aplicables enlas respuestas remotas.

Están destinadas fundamentalmente a entorpecer el proceso de in-geniería inversa durante un ataque, o el funcionamiento del softwarecuando es usado por un usuario ilegítimo.

Degradación del rendimiento

Consiste en degradar el rendimiento del software pirateado, atentan-do contra la disponibilidad del mismo. Por ejemplo, una vez detecta-da una modificación, el software ejecutará ciclos insertados a lo largodel grafo de control de flujo del software. Estos ciclos realizan unagran cantidad de iteraciones ejecutando un código “basura”, por loque retardan considerablemente la ejecución del software.

Un usuario ilegítimo verá que la aplicación se retarda más de lo de-bido en ejecutar cada funcionalidad, lo que puede forzarlo a desecharla versión pirateada de la misma.

Por otra parte, este tipo de respuestas fuerza al atacante a ejecu-tar todas las funcionalidades del software en busca de algún retardoinusual que evidencie la respuesta ante una modificación, dificultan-do de esta forma el ataque.

3.3 componente de respuesta ante modificación 45

Degradación del funcionamiento

Consiste en degradar el funcionamiento del software, casi siemprecorrompiendo los datos de forma gradual, lo que conlleva a que seemitan salidas erróneas o que termine abruptamente la ejecución.

Como se puede apreciar, este tipo de respuesta también afecta di-rectamente al usuario ilegítimo pues, puede obtener resultados noválidos durante una operación, forzándolo también a desechar la ver-sión pirateada del software.

El resultado de cara al atacante será el mismo que en la degrada-ción de rendimiento. Se verá forzado a observar todas las variablesde salida en busca de algún procesamiento erróneo que evidencie larespuesta ante una modificación, retardando también de esta formael ataque.

Tolerancia al ataque

Los mecanismos descritos hasta el momento suponen una degrada-ción o modificación en la funcionalidad de la aplicación en respuestaa un ataque malicioso. Todos ellos presentan el inconveniente de queuna activación errónea o accidental de la componente de respuesta(no motivada por un ataque), puede acarrear perjuicios a un usuariolegítimo.

La tolerancia al ataque, a diferencia de las anteriores tipos de res-puesta, no muestra una respuesta evidente al atacante o usuario ile-gítimo, sino que trata de restablecer el software a su estado original,corrigiendo las modificaciones realizadas por un atacante.

Este tipo de respuesta es similar a la tolerancia ante fallos de los sis-temas confiables, pudiéndose establecer, de forma general, una equi-valencia entre fallo (accidental) y ataque (deliberado). El sistema con-fiable es capaz de recuperarse tras una falla y volver a un estado esta-ble con niveles normales de funcionamiento, al igual que el softwarerestablece las modificaciones realizadas por el atacante a su estadoinicial. De esta forma, el atacante nunca observará respuesta algunadel mecanismo de protección, por lo que se dificulta el ataque paradesactivar el mecanismo de protección.

Siguiendo este esquema, Chang and Atallah (2002) proponen elempleo de “guardas” que garantizan la detección de un ataque me-


diante el control de integridad del código del software y la restituciónde dicho código por el original.

Jakubowski et al. (2009) proponen emplear como componente derespuesta ante una modificación (sea deliberada o no), la restauracióndel código modificado por el original al igual que Chang and Atallah(2002). Jakubowski et al. realiza su propuesta combinando técnicasdel área de la seguridad de software y los sistemas tolerantes a fallos(Brosch et al., 2011). El autor propone un software tolerante a modi-ficación (tamper tolerant software) en lugar de un software resistentea modificación. De los sistemas tolerantes a fallos toma los elemen-tos de redundancia mediante replicación y diversificación de código(igual que Anckaert et al., 2007; Dedic et al., 2007; Schrittwieser andKatzenbeisser, 2011) y puntos de restauración. Hace uso de mecanis-mo de votación (Linda and Manic, 2011) para calcular los resultadosde múltiples componentes redundantes y seleccionar el valor de ocu-rrencia más frecuente. Del área de la protección de aplicaciones, incor-pora verificaciones de integridad, empleando la técnica de ObliviousHashing propuesta por Chen et al. (2003) o las Expresiones de Verifi-cación de Integridad (Integrity Checking Expressions (ICE)) propuestaspor el propio autor en (Jakubowski et al., 2007).

3.4 privacidad

Un mecanismo para el control de integridad, debe ser capaz de detec-tar cambios no autorizados, tanto sobre el software como del propiomecanismo de protección. Dado que los mecanismos para el controlde integridad no proveen por si mismos privacidad, diversos auto-res proponen combinarlos con técnicas que proveen privacidad, paraevitar su fácil identificación y posterior desactivación por parte delatacante.

Entre los mecanismos más empleados para garantizar la privaci-dad con mayor o menor nivel de seguridad, están el cifrado (Cap-paert et al., 2008; Chow et al., 2003; Michiels, 2010) y la ofuscación(Collberg and Thomborson, 2002; Dalla Preda and Giacobazzi, 2009),siendo menos usado la auto-modificación (Cai et al., 2007; Giffin et al.,2005). Aunque la diversidad de código (Anckaert et al., 2004; Schritt-wieser and Katzenbeisser, 2011) es menos empleada para proveer pri-

3.4 privacidad 47

vacidad directamente, es fundamental su empleo para evitar ataquespor comparación o colisión (ataque empleado comúnmente para des-cubrir marcas de agua en aplicaciones, Nagra et al., 2002), una vezque el atacante localice algún componente de verificación o respues-ta.

El empleo del cifrado para garantizar la privacidad puede estarintegrado en una misma solución (ver procedimiento de verificaciónbasado en uso, epígrafe 3.2.2) o aplicarse de forma independiente(Michiels, 2010), aunque de esta forma puede ser violentado dada ladificultad de ocultar la clave de cifrado (Billet et al., 2005; Goubinet al., 2007).

En el caso de la ofuscación, lograr una adecuada ofuscación de lasinstrucciones de un software puede ser difícil en algunos casos (Baraket al., 2001; Goldwasser and Kalai, 2005). Por esta razón, además derealizar una ofuscación sintáctica, ya sea de las instrucciones o lainformación precalculada (Horne et al., 2002; Jacob et al., 2007), esnecesario lograr una ofuscación semántica (o del comportamiento)del mecanismo de protección (Dalla Preda and Giacobazzi, 2009).

3.4.1 Ofuscación sintáctica

Se considera una ofuscación sintáctica o estructural cuando se evitaque se expongan directamente las instrucciones o los datos del meca-nismo de protección ante el atacante, ya sea empleando técnicas decifrado u ofuscación.

Trabajos que combinan el cifrado de código y la auto-verificaciónde integridad pueden ser vistos en (Cappaert et al., 2008; Lee et al.,2005; Li et al., 2009a), garantizándose los atributos de integridad y pri-vacidad en una misma propuesta. Por ejemplo, Cappaert et al. (2008)propone una red de guardas de cifrado. Sus guardas se encargande descifrar bloques de código para su ejecución, empleando en elloclaves obtenidas a partir de calcular un resumen de otra porción decódigo. Si dicho código es modificado, el cifrado que depende de esteserá incorrecto.

Aucsmith (1996) propone insertar diferentes segmentos de códigoen un software, con el objetivo de ofrecer resistencia ante modificacio-nes maliciosas. Dichos segmentos de códigos son denominados Ker-


nel de Verificación de Integridad (Integrity Verification Kernel (IVK))y combina técnicas de cifrado de código, código automodificable yofuscación en una misma solución.

Horne et al. (2002) optaron por ofuscar los resúmenes precalcula-dos para realizar las comparaciones. Diseñaron su mecanismo paraque coexistiera con técnicas de marcas de aguas estáticas, con el ob-jetivo de brindarles protección contra modificación. El uso de marcasde agua estáticas implica que el mecanismo pueda ser susceptible aataques por colisión (Nagra et al., 2002). La comparación de dos ejecu-tables con marcas diferentes no solo revelaría la posición de la marca(en caso que no estuviese ofuscada), también revelaría la posición delvalor resumen precalculado de la misma, por ser diferente de un soft-ware a otro. Si se almacenaba el valor resumen junto al comprobador,además de revelar su posición por ataque de colisión, no se podríanformar redes circulares de chequeo. Como vía de solución, el autorle agregó a cada intervalo de código a verificar un corrector de 32

bits de información, tal que el resumen precalculado de dicho inter-valo (la concatenación del segmento de código, la marca de agua y elcorrector de 32 bits) sea siempre un valor constante, aún cuando lasmarcas de agua sean diferentes.

3.4.2 Ofuscación semántica

En este contexto, el objetivo principal de la ofuscación semántica (di-námica) es evitar que se expongan detalles del comportamiento delmecanismo del protección de cara al atacante durante un análisis di-námico del software (Schrittwieser and Katzenbeisser, 2011).

Ofuscar el comportamiento del mecanismo de protección es impor-tante dado que, durante la fase de análisis dinámico, el atacante escapaz de obtener mucha más información del mecanismo de protec-ción que en un análisis estático.

Un ejemplo de ofuscación del comportamiento es el propuesto porChang and Atallah (2002); en lugar de emitir un error tras un ataque,trata de restaurar el código modificado, por lo que el atacante nun-ca ve una respuesta por parte del sistema. Una propuesta similar esrealizada por Jakubowski et al. (2009), estableciendo un mecanismotolerante a ataques, en el cual el atacante no percibe respuesta alguna

3.4 privacidad 49

del mecanismo de protección tras un ataque, pues las modificacionesson corregidas por el propio mecanismo de protección.

Para lograr una ofuscación del comportamiento del mecanismo deprotección, diferentes autores han introducido componentes con uncomportamiento no-determinista en el diseño del mecanismo de pro-tección. Un ejemplo es el diseño del IVK de Aucsmith (1996). El autorplantea el uso de múltiples hilos de ejecución en el software para con-fundir al atacante a la hora de determinar cuál es el hilo correcto aseguir. Otro ejemplo es el propuesto por Tan et al. (2007). El autorpropone que tanto las detecciones como las modificaciones puedenser probabilísticas. Además propone el empleo de respuestas cautelo-sas no evidentes para el atacante; la degradación del rendimiento delsoftware y la corrupción de punteros globales.

Otro propuesta interesante es realizada por Anckaert et al. (2007).Este trabajo no se basa en la técnica de auto-verificación de integridadde forma directa, pero sí logra establecer una resistencia ante ataquespor modificación mediante la ejecución no-determinista del software.Su propuesta consiste en la replicación de diferentes bloques de códi-go del software, diversificándolos y seleccionándolos de forma alea-toria en tiempo de ejecución. Con esto logra, para una misma entradade datos, la ejecución aleatoria de diferentes caminos (random walks)en el Grafo de Control de Flujo (GCF) del software. Si el número debloques replicados es alto, la probabilidad de que se ejecute el mismocamino del GCF en cada ejecución es baja. Un código modificado du-rante el ataque, puede que no se vuelva a ejecutar, confundiendo deesta forma al atacante.

Por su parte Dedic et al. (2007) presenta una propuesta basada enun conjunto de comprobadores, diversificados y distribuidos aleato-riamente, para la verificación de integridad. Cada comprobador esresponsable de verificar uno de los fragmentos del programa. La de-tección del ataque se hará efectiva cuando fallen al menos un númerodeterminado de verificaciones, por lo que se tiene un umbral de de-tección de modificación. De esta forma la detección ante modificaciónes no-determinista.

Como se ha podido apreciar, existe una tendencia a diseñar sis-temas auto-verificación de integridad que incorporan elementos dealeatoriedad en su funcionamiento, con un comportamiento no deter-


minista. Bajo un modelo de amenaza de host no confiable, lo necesa-rio es detectar el ataque, pero tanto la detección como la respuestapueden ser no-deterministas y el mecanismo de protección no dejade ser efectivo.

Del área de sistemas confiables y tolerantes a fallos se incorporanconceptos, fundamentalmente el de la tolerancia a fallos, por la ana-logía entre el concepto de fallo y ataque que al final repercute en laintegridad o el funcionamiento normal del software.

3.5 evaluación de la seguridad

Es necesario destacar que resulta difícil realizar una evaluación cuan-titativa y objetiva de la seguridad de un sistema en sentido general(Verendel, 2009). Particularmente, existen diversos factores, sobre to-do subjetivos, que hacen difícil la evaluación de los recursos reque-ridos por un atacante para violentar un mecanismo de protección.Entre estos factores se encuentra: (1) la habilidad del atacante; cono-cimiento y experiencia sobre el manejo de técnicas y herramientas deingeniería inversa de aplicaciones y (2) el nivel de motivación del ata-cante. Por esta razón la evaluación cuantitativa suele establecerse entérminos prácticos como el límite inferior de recursos (tiempo y ca-pacidad de cómputo) necesarios para lograr un ataque satisfactorio.Como se comentó anteriormente, en la práctica todos los mecanismosde protección pueden ser violentados con más o menos esfuerzo, porlo que la intención de cualquier sistema de protección es retardar unataque satisfactorio el mayor tiempo posible.

Dado que es imposible para los diseñadores de los mecanismos deprotección, conocer y tener en cuenta todos los posibles tipos de ata-ques, técnicas y herramientas de las cuales se puede hacer valer unatacante, se hace necesario disponer de un modelo de evaluación dela seguridad que sea flexible y escalable en el tiempo. Un árbol deataque (Schneier, 1999) puede ser, entre otras, una alternativa paracuantificar el esfuerzo estimado (aproximado) del atacante en violen-tar un mecanismo de protección, en este caso de auto-verificación deintegridad.

Por otro lado, se puede cuantificar el nivel de privacidad alcanza-do por el mecanismo de protección, aplicando el concepto de fuga

3.5 evaluación de la seguridad 51

de información (information leakages) (Backes et al., 2009) del área deevaluación cuantitativa del flujo de información (Smith, 2009).

3.5.1 Árboles de ataque

Los árboles de ataque proveen una vía metodológica formal para des-cribir la seguridad de un sistema en función en un conjunto de po-sibles ataques. Este concepto fue definido inicialmente por Schneier(1999) y diferentes autores lo han aplicado en la evaluación de técni-cas de resistencia a la modificación (Jin and Myles, 2007; Liem et al.,2008; Piazzalunga et al., 2007; Salvaneschi and Piazzalunga, 2008).

En un árbol de ataque, el nodo raíz constituye el objetivo principaldel atacante, los hijos de este nodo representan ataques específicos.Los nodos del último nivel, por consiguiente, representan los ataquesque no pueden ser refinados. Un refinamiento en el ataque (pasarde un nivel a otro) puede realizarse de forma conjuntiva (“and”) odisyuntiva (“or”). El primer caso representa diferentes pasos paraalcanzar el mismo objetivo (necesidad de cumplir todos los ataquesde un nivel), el segundo caso son alternativas de ataques.

Una vez conformado el árbol, se le asigna un peso a cada nodo,representando el esfuerzo para lograr dicho ataque de forma satisfac-toria. El nivel de seguridad de un mecanismo de protección se definecomo función del esfuerzo necesario para lograr el objetivo principal,recorriendo una rama del árbol. La idea es hacer este valor tan gran-de como se pueda, dando lugar a un mayor esfuerzo por parte delatacante para lograr su objetivo.

El principal inconveniente, es que el árbol de ataque puede ser muygrande, y por ello los autores se limitan a representar un subconjuntode este (Piazzalunga et al., 2007). Otro inconveniente importante estáen la forma en que se determina el peso de cada nodo (ataque). Estepeso, por ejemplo, representa el tiempo de un ataque satisfactorio enminutos, dicho tiempo puede ser subjetivo y variar en dependenciade muchos factores (habilidades y herramientas con que cuente unatacante).

Otros autores (Ariss et al., 2011; Jürgenson and Willemson, 2008,2010; Kordy et al., 2010, 2011; Saini et al., 2008; Whitley et al., 2011)


han realizado extensiones o modificaciones a la propuesta original deSchneier.

3.5.2 Evaluación cuantitativa del flujo de información

En el ámbito de la seguridad de aplicaciones, se está empleando laevaluación cuantitativa del flujo de información (Quantitative Informa-tion Flow (QIF)) como herramienta teórica para cuantificar el gradode protección de la información secreta manejada por un software.A diferencia del método de no-interferencia (von Oheimb, 2004), queúnicamente determina si un programa es totalmente seguro o no, elanálisis QIF permite cuantificar diferentes niveles de seguridad, locual es más práctico en aplicaciones reales.

En años recientes, el interés por tener en cuenta aspectos cuantita-tivos del flujo de información ha estado motivado por dos razonesfundamentales (Alvim et al., 2010; Hamadou et al., 2010):

1. Se han considerado aspectos y técnicas probabilísticas en el dise-ño y análisis de protocolos y sistemas. Esto está fundamentadopor el hecho que los datos a proteger están sujetos a conside-raciones y análisis estadísticos bajo distribuciones de probabili-dad.

2. Los protocolos utilizan, a menudo, primitivas basadas en uncomportamiento aleatorio para ocultar (ofuscar) el vínculo entrela información que debe protegerse y los resultados observables,o sea, la relación entrada/salida.

El concepto de canal ruidoso (noisy channel) ha sido empleado enla modelación de protocolos (Chatzikokolakis et al., 2008) y softwarepara ocultar el flujo de información (information flow)(Malacaria andHeusser, 2010). La idea es que la entrada del canal o software, re-presenta la información que debe permanecer en secreto y la salidarepresenta la información observable o pública. Por citar un ejemplo,en un sistema de voto electrónico, las entradas serían cada uno delos votos de los participantes de forma independiente, las cuales de-ben ser secretas y anónimas, siendo el resultado total de la votaciónla salida observable. Otro ejemplo lo constituye el mecanismo de au-tenticación de un software, en el cual los datos de autenticación son


secretos para cada usuario y la respuesta al resultado de la autentica-ción, sea satisfactoria o no, es la información observable.

El ruido del canal es generado por el esfuerzo del protocolo (osoftware) para ocultar el vínculo o la relación entre la informaciónsecreta y la observable, generalmente por medio de mecanismos alea-torios. Consecuentemente, sea e una entrada y s una salida de uncanal de comunicaciones. La probabilidad de ocurrencia de la salidas dada la entrada e, está determinada por una distribución de pro-babilidad condicional p(s | e). De forma similar, la probabilidad deocurrencia de una entrada e dada la salida s, está determinada por laprobabilidad inversa p(e | s) = p(s | e)p(e)/p(s) (teorema de Bayes).La probabilidad p(e) es la probabilidad a priori de e, mientras quep(e | s) es la probabilidad a posteriori de e, una vez conocida la salidas.

Estas distribuciones de probabilidad determinan la entropía y laentropía condicional de una entrada respectivamente. Representan laincertidumbre sobre la entrada, antes y después de observar la sali-da. La diferencia entre la entropía y la entropía condicional es refe-rida como información mutua (mutual information) y expresa cuantaincertidumbre o información sobre la entrada se pierde o se gana res-pectivamente al observar la salida. De forma general, la informaciónmutua representa cuanta información secreta se ha filtrado del canalo software. La fuga máxima de información se corresponde con lacapacidad del canal que es por definición, la máxima informaciónmutua que puede ser obtenida variando la distribución de probabi-lidad de la entrada. Por otro lado, la fuga de información es cerocuando existe una independencia estadística entre las entradas y lassalidas.

Un mecanismo de protección de software que pretenda incorporaratributos de privacidad ante ataques dinámicos de ingeniería inversa,debe lograr en el caso ideal, que la fuga de información del meca-nismo sea cero. En este sentido, la componente de software sujeta aataque recibe un conjunto de estímulos o modificaciones (entradas)y emite un conjunto de respuestas (salidas) que son coleccionadas yanalizadas por el atacante a fin de evaluar el éxito de sus acciones(relación ataque-respuesta). El objetivo del mecanismo de protección


es minimizar la información mutua entre las entradas y las salidasmediante un comportamiento no determinista.

Varias son las propuestas realizadas para formalizar la definiciónde QIF basadas en la teoría de la información. Algunas propuestasse basan en la entropía de Shannon (Clark et al., 2007; Malacaria,2007; Robling Denning, 1982), entropía mínima (min-entropy) (Alvimet al., 2010; Smith, 2009), entropía de acierto (guessing entropy) (Bac-kes et al., 2009; Köpf and Basin, 2007) y capacidad del canal (channelcapacity)(Malacaria and Chen, 2008; McCamant and Ernst, 2008; New-some et al., 2009).

Alvim et al. (2010) afirma que en el caso probabilístico, la noción de“fuga de información” debe ser reconsiderada. Afirma que cuandoun mismo secreto, puede tener diferentes observaciones (acorde auna distribución de probabilidad determinada), la diferencia entre laentropía a priori y a posteriori puede ser negativa. En este sentidoAlvim et al. (2010) y Smith (2009) recomiendan emplear la noción deinformación mutua basada en la entropía mínima (min-entropy) deRényi, además de modelar el conocimiento extra que pueda tener elatacante sobre la entrada antes de observar las salidas.

En el anexo A se exponen brevemente los principales elementos dela teoría de la información relacionados con el cálculo cuantitativodel flujo de información (Thomas M. Cover, 2006).

3.6 conclusiones

El estudio del estado del arte realizado se centra en las técnicas queofrecen resistencia ante la manipulación de componentes de software,específicamente la técnica de auto-verificación de integridad. Al res-pecto se propuso una clasificación o taxonomía que permitió identifi-car las tendencias y buenas prácticas del diseño de estos mecanismos.

Un primer elemento significativo del diseño, lo constituye el hechode dividir el mecanismo de protección en dos componentes funciona-les. El primero se encargaría de realizar las verificaciones de integri-dad y el segundo sería responsable de brindar una respuesta ante ladetección de una manipulación. Adicionalmente, estos componentesdeben ser replicados y distribuidos por toda la componente de soft-

3.6 conclusiones 55

ware a proteger, con el objetivo de garantizar una redundancia en laprotección.

Se concluye la necesidad de emplear técnicas que proveen privaci-dad, para proteger el propio mecanismo de control de integridad. Enconsecuencia, se pudo apreciar la presencia de diseños no determinis-tas como vía para garantizar una ofuscación semántica del mecanis-mo de protección.

No se pudo identificar un consenso sobre una vía para la evalua-ción de la eficacia del mecanismo de auto-verificación de integridadfrente ataques realizados, ya sea en términos de tiempo de ataque,consumo de memoria, etc. Esto impide adicionalmente la compara-ción de la fortaleza alcanzada entre distintas propuestas.

En consecuencia, se realizó un estudio para evaluar el esfuerzo deun atacante mediante un árbol de ataque y se determinó el uso de laevaluación cuantitativa del flujo de información como métrica paracuantificar el nivel de ofuscación.

4M O D E L O N O D E T E R M I N I S TA PA R A L AA U T O - V E R I F I C A C I Ó N D E I N T E G R I D A D

En el presente capítulo se exponen los principales elementos de unmodelo para la auto-verificación de integridad de componentes desoftware. El modelo se basa en una red de auto-verificación de inte-gridad con un comportamiento no determinista que permite una ofus-cación semántica de la misma. Su diseño y concepción están guiadospor una serie de requisitos y buenas prácticas extraídos del análisisdel estado actual de la técnica.

En la sección 4.1 se exponen los requisitos de seguridad que debecumplir el modelo para garantizar resistencia ante manipulaciones.Seguidamente en la sección 4.2 se describe la estructura y el funcio-namiento de la red de auto-verificación de integridad no deterministapropuesta. Por último, en la sección 4.3 se realiza un análisis funcio-nal de la propuesta.

4.1 requisitos de seguridad

A continuación se describen los requisitos de seguridad que debecontemplar el modelo.

1. Seguridad distribuida. El mecanismo de protección estará dis-tribuido a lo largo de todo el software. De esta forma, la loca-lización y desactivación de una o varias partes del mecanismono invalidará, necesariamente, la protección.

2. Verificación interdependiente. Se realizarán verificaciones cru-zadas y entre las distintas partes del mecanismo de protección,existiendo una verificación redundante entre las mismas.

57

58 modelo no det. para la auto-verificación de integridad

3. Comportamiento no determinista. Tanto las verificaciones a rea-lizar por las distintas partes del mecanismo, como las repuestasante modificaciones serán no deterministas. De esta forma elcomportamiento del modelo podrá ser distinto en cada ejecu-ción del software.

4. Complementariedad entre privacidad e integridad. El modelode control de integridad estará dotado de atributos de privaci-dad a través de la ofuscación sintáctica y semántica.

5. Balance adecuado y ajustable entre disponibilidad y seguridad.El modelo deberá garantizar los niveles de seguridad especi-ficados sin que ello suponga un menoscabo inaceptable en ladisponibilidad del software. El ajuste del balance entre dispo-nibilidad y seguridad, durante la fase de implantación de laprotección, permitirá que el mecanismo de seguridad no tengaun efecto perjudicial durante el uso del software por parte deusuarios legítimos.

4.2 red de auto-verificación de integridad no determi-nista

La presente propuesta consiste en una red de auto-verificación de in-tegridad no determinista, diseñada bajo los atributos de seguridadantes descritos en la sección 4.1. Dicha red se integra en la componen-te de software a proteger mediante un conjunto de transformaciones.Esto permite que se realicen controles de integridad dinámicos, ofre-ciendo resistencia ante ataques por manipulación.

En adelante, se nota como P el programa a proteger y se representamediante la terna:

P ≡ (M,O,F); (1)

M = {m1,m2, . . . ,mn}; mi = GCF(N,A) (2)

O = {o1,o2, . . . ,on} (3)

F = {f1, f2, . . . , fn}; fi = hash(oi) (4)

Donde M es el conjunto de métodos (funciones) que conformanel programa a proteger. Cada método mi está definido por su Grafo

4.2 red de auto-verificación de integridad no determinista 59

de Control de Flujo, siendo GCF un grafo dirigido (Bang-Jensen andGutin, 2002) en el cual N(GCF) es el conjunto de nodos o bloquesbásicos, y A(GCF) es el conjunto de arcos que indican la transiciónentre nodos durante la ejecución de P. Un nodo se define como unconjunto de instrucciones I = {i1, i2, . . . , in}, cuya primera instruccióni1 es el destino de un salto en la ejecución del programa, y cuyaúltima instrucción in genera un salto en el control de flujo.

Así mismo, se nota como O al conjunto de objetos de P que es ne-cesario proteger frente a manipulaciones. Cada objeto oi puede estarconstituido por uno o varios bloques básicos del GCF o un conjuntode datos. A su vez, asociado al conjunto O, se define el conjunto defirmas de identidad F. Cada fi se obtiene del correspondiente oi me-diante algún tipo de función resumen hash en una etapa previa a ladistribución de la aplicación.

A grandes rasgos, la red de auto-verificación de integridad no de-terminista (red AVI) está compuesta por dos componentes: Detección(ver epígrafe 4.2.1) y Respuesta (ver epígrafe 4.2.2). Ambos componen-tes son adicionados al programa a proteger, permitiendo que se llevena cabo los controles de integridad. El proceso de auto-verificación rea-lizado por la red AVI durante la ejecución de P, puede ser visto en lafigura 11.

Autoverificación de integridad

<<goal>>

Verificar integridad

<<abstract>>

Respuesta

Detección

<<information>>

Bandera de respuesta

<<control>>

<<abstract>>

Objetos a verificar

<<achieve>>

<<physical>>

Caso de prueba

<<control>>

<<abstract>>

Recurso de la aplicación

Respuesta

Figura 11 Proceso de auto-verificación de integridad.

El proceso está controlado por el caso de prueba con que se ejecuteP. Para cada caso de prueba en particular, se activarán distintas partes


del GCF de los métodos Mi presentes en P y en correspondencia, loscomponentes de Detección y Respuesta distribuidos en estos.

Internamente, el proceso está compuesto por dos subprocesos: De-tección y Respuesta, los cuales son ejecutados por los componentes deigual nombre antes mencionados.

El conjunto de objetos O a proteger constituye la entrada al sub-proceso de Detección, donde se determina si algún elemento de O hasufrido alguna manipulación deliberada. En caso afirmativo, se pa-sa al subproceso de Respuesta, obteniéndose como resultado algunaacción ante la manipulación detectada.

Existe una probabilidad asociada a realizar las tareas de detección.Por ello, tanto el subproceso de Detección como el de Respuesta tienenun carácter no determinista.

4.2.1 Componente de detección

El componente de detección está formado por el conjunto de verifica-dores C encargados de detectar modificaciones no autorizadas sobreel conjunto de objetos O. Está definido por la tupla:

CompDetec = (C,n∐

i=1

Oi,n∐

i=1

Fi,B,pc,hvmax); (5)

C = {c1, c2, . . . , cn}; ∀ci,∃(Oi, Fi) | ci : Oi → Fi (6)

Oi = {oi1,oi2, . . . ,oim}; Oi ⊂ O (7)

Fi = {fi1, fi2, . . . , fim}; Fi ⊂ F (8)

B = {b1, . . . ,bn} (9)

hvmax : umbral de verificación (10)

pc : probabilidad de verificación (11)

Cada verificador ci tiene asignado un subconjunto de verificaciónOi, y su conjunto de firmas confiables Fi calculadas previamente a ladistribución del software. Las verificaciones se realizan con una pro-babilidad pc, por lo que los verificadores tienen un comportamientono determinista. El conjunto de banderas B realiza la función de re-curso compartido entre el componente de Verificación y de Respuesta,permitiendo su comunicación. De esta forma, las verificaciones y lasrespuestas se encuentren separadas espacial y temporalmente dentro


del software. El umbral de verificación h controla el número máximode verificaciones recibidas por cada nodo. Esto impide que se haganverificaciones innecesarias, lo cual atenta negativamente contra la dis-ponibilidad del software.

Los objetos a verificar están distribuidos entre los diferentes sub-conjuntos de verificación de forma que:

•∐n

i=1Oi = O

• ∀oi,∃(Ol,Ok) | Ol ∩Ok = oi

Es decir, todos los objetos son verificados y esta verificación es re-dundante e interdependiente.

Para llevar a cabo la verificación de integridad, cada verificador cirealiza las siguientes tareas (ver figura 12):

1. Cálculo de firmas. Se calcula en tiempo de ejecución el conjuntode firmas F‘i = {f‘i1, f‘i2, . . . , f‘im} que caracterizan de formaunívoca los m objetos del conjunto asociado Oi.

2. Verificación. Se verifica la integridad de cada objeto oij ∈ Oi,mediante la comparación entre su firma de identidad fij y lafirma calculada f‘ij. Si no hay coincidencia entre ambas, es por-que se ha producido una modificación del objeto, y en ese casose activa aleatoriamente una bandera bk.

Detección

<<goal>>

Detectar modificación no autorizada.

<<abstract>>

Objetos a verificar (Oi)

<<achieve>>

Cálculo de firmas Verificación

<<information>>

Conjunto de firmas (F’i)

<<information>>

Conjunto de Firmas de identidad (Fi)

<<information>>

Bandera de respuesta (bk)

<<information>>

Conjunto de Banderas (B)

<<supply>><<supply>>

Figura 12 Subproceso de detección de modificación.


En el algoritmo 1 puede verse el pseudocódigo correspondiente aun verificador ci. A su funcionalidad básica se le han añadido doscomponentes, el primero (umbral de verificación) reduce el impactode la protección sobre el rendimiento de la aplicación a la vez que dis-minuye el flujo de información hacia el exterior de la aplicación anteun posible ataque. El segundo (probabilidad asociada) añade aleato-riedad en la verificación y en la selección de la respuesta asociada,incrementando la confusión entre la causa y el efecto.

Algoritmo 1: Algoritmo de verificación de integridad.

1 foreach oij ∈ Oi do2 if oij → VerificacionesRecibidas < hvmax then3 if RealizaVerificacion(pc) then4 fij‘← CalcularFirma(oij)

5 fij ← ObtenerFirmaIdentidad(oij, Fi)6 if (fij 6= fij‘) then7 seleccionar aleatoriamente k tal que 1 6 k 6 |B|

8 bk ← verdadero

9 oij → VerificacionesRecibidas+ = 1

Como se puede apreciar, en primer lugar el verificador ci chequeael número de verificaciones realizadas sobre el objeto oij (línea 2),si este número es menor que el umbral hvmax, se continua con elproceso de verificación. De esta forma se reduce la probabilidad deque un mismo objeto sea verificado reiterativamente (p.e. cuando elverificador se encuentra dentro de un bucle). Esto produciría una rá-pida degradación del rendimiento a la vez que aumentaría el númerode respuestas ante una posible modificación, ofreciendo una mayorinformación al atacante sobre la presencia del mecanismo de protec-ción.

Acto seguido se ejecuta una función que genera un valor verdaderoo falso de forma no determinista con probabilidad pc y 1 − pc respec-tivamente (línea 3). Esta función hace que las verificaciones tenganun carácter no-determinista en el mecanismo de protección. En casode obtenerse un valor verdadero, se calcula la firma fij‘, se recupera


la firma de identidad fij y se procede a verificar la integridad (líneas4-6). Si se detecta una violación de la integridad, se activa de formaaleatoria una bandera bk con una probabilidad 1

|B| , poniendo su valora verdadero (línea 7-8). Por último se incrementa el número de vecesque ha sido verificado el objeto oij (línea 9).

Según esto, para conseguir que la modificación de un objeto paseinadvertida debe modificarse también el verificador o las firmas deidentidad asociadas. Idealmente para obtener una protección comple-ta, el conjunto de objetos de verificación O debe incluir el conjuntode verificadores C y el conjunto de firmas de identidad F. En la prác-tica dependiendo de la implementación que se lleve a cabo, podránexistir verificadores que queden sin protección, en dependencia delas propiedades de la función resumen empleada al calcular la firmade identidad.

4.2.2 Componente de respuesta

El componente de respuesta está formado por el conjunto de respues-tas R y el recurso compartido de banderas B. Se define como:

CompResp = (R,B,pr); (12)

R = {r1, r2, . . . , rn}; ∀rk, ∃bk | bk activa rk (13)

pr : probabilidad de ejecución de una respuesta activada (14)

Este componente está encargado de ejecutar la respuesta rk, previoa su activación por parte de algún verificador ci ante la detección deuna modificación mediante una bandera bk asociada a dicha respues-ta. Tiene un comportamiento no determinista, pues una vez que hasido activada, se ejecuta con una probabilidad pr.

Los tipos de respuestas pueden ser diversos, por lo que ante unamisma modificación, el atacante puede observar diferentes comporta-mientos de la aplicación (ver figura 13).

La cantidad de respuestas rk debe ser mayor que la cantidad de ve-rificadores ci. Esta proporción está dada por dos razones fundamen-tales. En primer lugar, el atacante puede decidir eliminar solamenteel componente de respuesta en lugar del componente de detección,


como una vía para desactivar el mecanismo de protección1. Al ser elnúmero de respuestas mucho mayor que los verificadores, el atacantedeberá optar por desactivar los segundos. En segundo lugar, mientrasmayor sea el número de respuestas, más baja será la probabilidad deque una respuesta sea activada. Esto garantiza que una vez que elatacante localice una respuesta, le resulte más difícil localizar nuevosverificadores a partir de su activación.

<<abstract>>

Respuesta

<<physical>>

Degradación del rendimiento

<<physical>>

Degradación del funcionamiento

<<physical>>

Tolerancia al ataque

<<physical>>

Respuesta nula

Figura 13 Tipos de respuesta.

El funcionamiento del componente de respuesta puede ser vistoen el algoritmo 2. La función EjecutaRespuesta(pr) realiza la mismafunción que RealizaVerificacion(pc) en el algoritmo 1, solo que eneste caso se le puede asociar un valor de probabilidad diferente.

Algoritmo 2: Algoritmo de respuesta.

1 if bi then2 if EjecutaRespuesta(pr) then3 ejecutar la respuesta rk

1 Al atacante le resulta más fácil localizar el componente de respuesta pues, duran-te el proceso de ingeniería inversa, las respuestas ante modificaciones le indica lapresencia del mecanismo de protección. Para más detalle refiérase al epígrafe 2.4.2.


4.2.3 Red de auto-verificación

A partir de los componentes de detección y respuesta previamentedefinidos, se conforma una red de auto-verificación de integridad nodeterminista, definida por la tupla:

RedAVI = (CompDetec,CompResp,GV ,GR) (15)

GV = (N,A) (16)

GR = (C,R;A) (17)

La configuración de la red de auto-verificación se especifica me-diante los parámetros de los componentes de verificación y respuesta,y los grafos de verificación GV y respuesta GR.

El grafo de verificación GV es un grafo dirigido o digrafo2 (DirectedGraphs) donde:

• N(GV) = C ∪O; representa los nodos que realizan verificacio-nes (verificadores) o reciben verificaciones (objetos). En este ca-so, un verificador puede ser a su vez objeto de verificación

• A(GV) = (ci,oj); es el conjunto de arcos que indican una verifi-cación de integridad de un verificador ci sobre el objeto oij.

Los nodos verificadores están caracterizados por su grado de sali-da (out-degree) d+GV

(ci), que indica la cantidad de nodos a los cualesci realiza controles de integridad3, mientras que los nodos objeto es-tán caracterizados por su grado de entrada (in-degree) d−GV

(oij), queindica la cantidad de nodos que verifican a oij.

Por otra parte, el Grafo de Respuesta GR es un grafo dirigido bipar-tito4 donde:

• C(GR) y R(GR) ; representa el conjunto de nodos de verificacióny de respuesta que conforman los nodos del grafo.

2 Véase Bang-Jensen and Gutin (2002), para más detalle sobre los grafos dirigidos.3 No debe confundirse el grado de salida del nodo con la cantidad de verificaciones

que realiza sobre cada nodo, la cual está limitada por el umbral de verificación (véasealgoritmo 1).

4 Véase Bang-Jensen and Gutin (2002), para más detalle sobre los grafos bipartitos.


• A(GR) = (ci, rj) es el conjunto de arcos que indican la activa-ción de una respuesta rj por un verificador ci ante la detecciónde una modificación. La activación se realiza mediante el con-junto de banderas B.

Los verificadores C, al formar parte tanto de GV como de GR, rea-lizan dos funciones; verificar la integridad de su conjunto de verifica-ción y activar los nodos de respuestas en caso de detectar modifica-ciones.

Dado que tanto las verificaciones como las respuestas son no de-terministas, un mismo verificador ci durante diferentes ejecuciones,puede adoptar uno de los siguientes estados:

no-verificación/no-respuesta : el verificador no realiza la ve-rificación de ningún objeto, por lo que no emite respuesta. Eneste estado el atacante no recibe ninguna respuesta, por lo quepuede considerar exitoso su ataque durante la ejecución en cur-so.

verificación/no-respuesta : el verificador detecta la modifica-ción realizada sobre algún objeto y activa aleatoriamente unarespuesta, pero esta no se ejecuta. En este estado el atacantetampoco recibe ninguna respuesta, por lo que puede considerarexitoso su ataque durante la ejecución en curso.

verificación/respuesta : el verificador detecta la modificaciónrealizada sobre algún objeto y activa una respuesta selecciona-da de forma aleatoria, la cual se ejecuta en el momento corres-pondiente. En este estado el atacante recibe una respuesta antela modificación realizada.

En una red mínima, conformada por un solo nodo de verificacióny uno de respuesta (probabilidades de verificación y respuesta de 0.5respectivamente), el atacante percibe una respuesta como promedioante su ataque por cada cuatro ejecuciones del software.

Dado que el Grafo de Verificación GV puede ser un grafo dirigidoacíclico (Directed Acyclic Graphs (DAG)) en caso de emplearse funcio-nes resúmenes unidireccionales, habrá un nodo con grado de entradacero (al no poderse realizar verificaciones cíclicas), por lo que dicho


nodo no será verificado en ningún momento. Como las verificacionesy las respuestas son no-deterministas, tras la modificación de un no-do, a un atacante le será difícil saber si está tratando con el nodo sinprotección o con un nodo que no ha sido verificado durante la ejecu-ción en curso. Por esta razón la seguridad de la red no se ve afectadasustancialmente por existir un nodo sin protección, evitándose la ne-cesidad de conformar redes circulares de protección.

4.2.4 Integración de la red AVI

La protección del programa P se lleva a cabo mediante la integraciónde la red AVI obteniéndose un programa modificado P‘ que preservala semántica original de funcionamiento.

Durante el proceso de protección (algoritmo 3), se realiza una seriede transformaciones sobre cada uno de los GCF de los distintos méto-dos de P, integrando los componentes de verificación y respuesta deforma distribuida. Los grafos de verificación y respuesta deben serconfigurados previamente a su integración con P.

Inicialmente se procede a particionar el conjunto de verificadoresC y de respuesta R, pertenecientes a los componente CompDetec yCompResp respectivamente, en varios subconjuntos: Ci y Ri. El totalde subconjuntos en cada caso debe ser igual al número de métodosde P (línea 1-2) para garantizar que se inserten nodos de verificacióny de respuesta en cada método. La inserción de los nodos se realizóteniendo en cuenta las siguientes restricciones:

•⋂n

i=1Ci = ∅;⋂n

i=1 Ri = ∅

• n = |M|

• ∀mi ∈M: |A(GCFi)| > |Ci|+ |Ri|

Se debe destacar que el tamaño de cada Ci y Ri es proporcional altamaño (número de arcos) pertenecientes al GCF del método Mi enel cual serán insertados.

Posteriormente, se extrae el GCFi de cada método mi (línea 4) y seprocede a integrar los correspondientes Ci y Ri combinando todos losnodos (línea 5-6). Para ello se selecciona aleatoriamente un subconjun-to de arcos AC y AR de A(GCFi) tal que |AC| = |Ci| y |AR| = |Ri| (línea


7). Cada arco original de AC y AR es sustituido por dos nuevos arcosque conectan los nodos originales con un nodo tomado aleatoriamen-te del conjunto Ci y Ri respectivamente (líneas 8-11).

Algoritmo 3: Integración de la red AVI.entrada :P, RedAVIsalida :P‘// particionar el conjunto de verificación y respuesta

1 generar Ci; i = 1, 2, . . . ,n2 generar Ri; i = 1, 2, . . . ,n3 foreach mi ∈M do4 GCFi ← ObtenerGCF(mi)

// adicionar los nodos de verificación y respuesta

5 N(G‘CFi)← N(GCFi)∪Ci

6 N(G“CFi)← N(G‘CFi)∪ Ri// reorganizar los arcos del GCF

7 seleccionar aleatoriamente (AC,AR) ⊆ A(GCFi)

8 foreach (ni,nj) ∈ AC do9 (ni,nj)→ (ni, ck), (ck,nj) | ck ∈ Ci

10 foreach (ni,nj) ∈ AR do11 (ni,nj)→ (ni, rk), (rk,nj) | rk ∈ Ri

12 F← CalcularFirmaIdentidad(O)

13 insertar F14 insertar B

Tomando como referencia el grafo de verificación, se procede a cal-cular las firmas de identidad del conjunto de objetos O (línea 12) y seinsertan en el programa (línea 13). Por último, se inserta en conjuntode banderas B (línea 14).

4.2.5 Ejemplo de integración de una red AVI no determinista

A modo de ejemplo, en el listado 1 se representa el código fuente(c++) de un programa que permite la clasificación de un triángulo.El punto de entrada del programa es el método Main() y partiendodel caso de prueba empleado por el usuario, el triángulo es clasifi-


cado en equilátero, isósceles, escaleno o no válido, mediante el métodoTriangleType().

Listado 1 Código fuente (c++) para la clasificación de un triángulo.

1 #include <stdio.h>

2 #include <iostream>

3 using namespace std;

4

5 #define INVALID 0

6 #define SCALENE 1

7 #define EQUILATERAL 2

8 #define ISOSCELES 3

9

10 int TriangleType(int a, int b, int c)

11 {

12 int type = INVALID;

13 if (((a + b)>c) && ((b + c)>a) && ((c + a)>b))

14 {

15 if ((a == b) && (b == c))

16 type = EQUILATERAL;

17 else if ((a == b) || (b == c) || ( c == a))

18 type = ISOSCELES;

19 else

20 type = SCALENE;

21 }

22 return type;

23 }

24 int Main(int argc, char* argv[])

25 {

26 int a = 0;

27 int b = 0;

28 int c = 0;

29 cin >> a;

30 cin >> b;

31 cin >> c;

32 int type = TriangleType(a,b,c);

33 if(type == EQUILATERAL)

34 printf(" Equilateral Triangle\n");35 else if(type == ISOSCELES)

36 printf(" Isosceles Triangle\n");37 else if(type == SCALENE)

38 printf("Scalene Triangle\n");39 else

40 printf(" Invalid Triangle\n");41 return 0;

42 } �Una representación gráfica del GCF de ambos métodos puede ser

visto en en la figura 14. En el interior de cada nodo se relacionan losíndices de las instrucciones que lo componen, según el orden de cada


instrucción en el listado 1. A su vez cada nodo tiene una etiqueta ni

que facilita su referencia.

2633

34

3637

41

(v)

n1

35

(f)

(v)(f)

3840

(v)(f)(v)

(v)

(v)

(v)

n2n3

n4

n8

n5

n6n7

(a) Main().

1213

15

1617

1820

22

(f)

(v)

(v)(f)

(v)(f)

(v)(v)(v)

n1

n2

n3n4

n5n6

n7

(b) TriangleType().

Figura 14 Grafo de Control de Flujo de los métodos del programa 1.

Definición del programa

Para este ejemplo, se desea verificar la integridad del nodo n1 perte-neciente al método TriangleType().


P ≡ (M,O,F);

M ={TriangleType,Main};

TriangleType =GCF(N,A)

N(GCF) = {n1,n2,n3,n4,n5,n6,n7}

A(GCF) = {(n1,n7), (n1,n2), (n2,n4),

(n2,n3), (n4,n6), (n4,n5),

(n6,n7), (n5,n7), (n3,n7)}

Main =GCF(N,A)

N(GCF) = {n1,n2,n3,n4,n5,n6,n7,n8}

A(GCF) = {(n1,n2), (n1,n3), (n2,n8), (n3,n4)

(n3,n5), (n4,n8), (n5,n6),

(n5,n7), (n6,n8), (n7,n8)}

O ={n1}

F ={hash(n1)}

Componente de detección

CompDetec = (C,n∐

i=1

Oi,n∐

i=1

Fi,B,pc,hvmax);

C = {c1, c2, c3, c4};

c1, (O1, F1) | {c2, c3, c4}→ {hash(c2),hash(c3),hash(c4)}

c2, (O2, F2) | {c3, c4}→ {hash(c3),hash(c4)}

c3, (O3, F3) | {c4,n1}→ {hash(c4),hash(n1)}

c4, (O4, F4) | {n1}→ {hash(n1)}

B = {b1,b2,b3,b4,b5}

pc = 0.5

hvmax = 1



CompResp = (R,B,pr);

R = {r1, r2, r3, r4, r5};

r1,b1 | b1 → r1

r2,b2 | b1 → r2

r3,b3 | b1 → r3

r4,b4 | b1 → r4

r5,b5 | b1 → r5

pr = 0.5

Red AVI

RedAVI = (CompDetec,CompResp,GV ,GR)

GV = (N,A);

N(GV) = {n1, c1, c2, c3, c4};

A(GV) = {(c1, c2), (c1, c3), (c1, c4), (c2, c3),

(c2, c4), (c3, c4), (c3,n1), (c4,n1)};

GR = (C,R;A);

C(GR) = {c1, c2, c3, c4,n1}

R(GR) = {r1, r2, r3, r4, r5}

A(GR) = {(c1, r1), . . . , (c1, r5), (c2, r1), . . . , (c2, r5),

(c3, r1), . . . , (c3, r5), (c4, r1), . . . , (c4, r5)}

En la figura 15a y 15b puede verse una representación de los grafosde verificación GV y respuesta GR respectivamente.


activación de respuesta

Leyenda

verificación

(a) GV .

1

2

3

4

1

2

3

4

5

(b) GR.

Figura 15 Ejemplo de grafo de verificación y respuesta.

Integración

A continuación se ilustra cómo se lleva a cabo la integración de lared de auto-verificación del ejemplo anterior, con el programa dellistado 1. Para ello se ha tomando como referencia el algoritmo deintegración 3 propuesto en la sección 4.2.45.

1. Generar Ci y Ri (líneas 1-2).El total de subconjuntos es n = 2 pues existen dos métodos enel programa.

C1 = {c1, c2} C2 = {c3, c4}

R1 = {r1, r2} R2 = {r3, r4, r5}

5 En cada punto se especifica las líneas correspondientes en el algoritmo.


2. Adicionar C1 y R1 al GCF de TriangleType() (líneas 5-6).

a) Para el método TriangleType():

N(G‘CF)← N(GCF)∪C1

N(G‘CF) = {n1,n2,n3,n4,n5,n6,n7, c1, c2}

N(G“CF)← N(G‘CF)∪ R1N(G“CF) = {n1,n2,n3,n4,n5,n6,n7, c1, c2, r1, r2}

b) Para el método Main():

N(G‘CF)← N(GCF)∪C2

N(G‘CF) = {n1,n2,n3,n4,n5,n6,n7,n8, c3, c4}

N(G“CF)← N(G‘CF)∪ R2N(G“CF) = {n1,n2,n3,n4,n5,n6,n7,n8, c3, c4, r3, r4, r5}

3. Reorganizar los arcos del GCF (líneas 7-11).

a) Para el método TriangleType():

AC = {(n3,n7), (n6,n7)}

(n3,n7)→ (n3, c1), (c1,n7) | c1 ∈ C1

(n6,n7)→ (n6, c2), (c2,n7) | c2 ∈ C1

AR = {(n2,n4), (n4,n5)}

(n2,n4)→ (n2, r1), (r1,n4) | r1 ∈ R1(n4,n5)→ (n4, r2), (r2,n5) | r2 ∈ R1


b) Para el método Main():

AC = {(n1,n2), (n1,n3)}

(n1,n2)→ (n1, c3), (c3,n2) | c3 ∈ C2

(n1,n3)→ (n1, c4), (c4,n3) | c4 ∈ C2

AR = {(n5,n6), (n7,n8), (n1,n2)}

(n5,n6)→ (n5, r3), (r3,n6) | r3 ∈ R2(n7,n8)→ (n7, r4), (r4,n8) | r4 ∈ R2(n4,n8)→ (n4, r5), (r5,n8) | r5 ∈ R2

En la figura 16a y 16b puede verse una representación gráfica delGCF de los métodod Main() y TriangleType() respectivamente, unavez que se insertaron los nodos y se reorganizaron los arcos.

n1

n2

n4n5

n8

(v)

n3

(f)

(v)(f)

n6

n7

(v)(f)

(v)

(v)

(v)

(v)

c3c4

r4

r3

r5(v)

(f) (v)

(v)

(v)

(a) Main().

n1

n2

n3

n4

n5

n6

n7

(f)

(v)

(v)(f)

(v)(f)(v)

(v)

(v)

c1

c2

r1

r2

(v)(v)

(v)

(v)

(b) TriangleType().

Figura 16 GCF protegidos de los métodos del programa 1.


En la figura 17 se aprecia una vista general de los dos grafos decontrol de flujo, con los arcos de verificación y activación de respues-ta.

n1

n2

n3

n4

n5

n6

n7

c1

c2

r1

r2

n1

n2

n4n5

n8

n3

n6

n7

c3c4

r4

r3

r5

Figura 17 Grafos de verificación y respuesta incorporados a los métodos.

4.3 análisis funcional del modelo propuesto

Suponga el siguiente escenario. Un atacante trata de comprometerel mecanismo de protección de un software para posteriormente dis-tribuirlo de forma ilegal y ser usado por un usuario ilegítimo (versección 2.1).

El mecanismo de protección del software sometido al ataque con-siste en una red de auto-verificación de integridad, diseñada bajo losatributos de seguridad y principios de diseño antes descritos.

4.3 análisis funcional del modelo propuesto 77

El ataque consiste en manipular el software para desactivar el me-canismo de protección, acorde al procedimiento de ataque descritoen la sección 2.4. En este caso, el comportamiento no deseado parael atacante, es la manifestación de una respuesta tras la detección deun ataque contra la integridad del software. De esta forma, el objetivodel atacante es desactivar cada uno de los nodos de la red. El atacantehabrá tenido éxito si el mecanismo de protección nunca brinda unarespuesta ante la modificación realizada. En caso contrario, tendráque repetir el proceso una y otra vez hasta lograrlo.

Si las respuestas ante un mismo ataque son diferentes y el tiempode respuesta es no determinista en cada ejecución, entonces la can-tidad de información, en términos de entropía (Alvim et al., 2010;Yasuoka and Terauchi, 2010) que brinda el mecanismo de protecciónal atacante, será menor que el brindado por un mecanismo de auto-verificación de integridad tradicional. Al existir un mayor caos o con-fusión ente la relación ataque-respuesta, la entropía del mecanismoaumentará, por lo el atacante necesitará realizar un mayor númerode ensayos o ejecuciones del software para obtener la cantidad deinformación necesaria para comprender el funcionamiento del meca-nismo de protección (ver Capítulo 5).

Ante la modificación de cada nodo, el mecanismo de control deintegridad puede no emitir una respuesta por dos motivos: (1) el ata-cante logró desactivar satisfactoriamente cada uno de los nodos o, (2)el mecanismo de protección no realizó la verificación durante la ejecu-ción en curso, aunque existe cierta probabilidad de que la verificaciónse realice en posteriores ejecuciones. Por este motivo, el atacante tie-ne que realizar un alto número de ensayos para observar si se brindauna respuesta (detección esperada) a su ataque.

Partiendo de las premisas expuestas con anterioridad, se puede re-tardar tanto el tiempo de localización de los nodos, así como el tiem-po para su desactivación y formular, de forma objetiva, las siguientesobservaciones.

desde el punto de vista del atacante . El hecho de que lasverificaciones y las respuestas ante ataques sean no determinis-tas, hace que el atacante emplee un gran esfuerzo para tener lacerteza de que se ha logrado desactivar el mecanismo de pro-tección por completo. Por otra parte, el atacante puede asumir


cierta tolerancia, considerando satisfactorio un ataque en el queel software pirateado falle su ejecución con una baja probabili-dad (p. ej. una de cada cien ejecuciones como promedio).

desde el punto de vista del usuario. La protección median-te un mecanismo de protección no-determinista generará des-confianza en los potenciales usuarios ilegítimos al carecer de lacerteza de que los resultados que genere el software sean correc-tos el 100 % de las veces. El esfuerzo y el coste necesario paracorregir los errores causados por la protección pueden ser supe-riores al coste que supone adquirir el software legal. El tiempoentre las fallas será tal que podrá ser aceptado como válido paraun atacante, pero no necesariamente para un usuario ilegítimo.La incertidumbre del correcto funcionamiento del software, uni-do al coste de corregir los fallos producidos por el mecanismode protección, puede forzar al usuario a rechazar un softwarepirateado.

Con esta propuesta se logra alcanzar un cierto nivel de seguridad,fundamentada en un enfoque de seguridad práctica, al establecer unconsenso entre el nivel de seguridad a lograr y la rentabilidad deaplicar el mecanismo de protección en el proceso de desarrollo desoftware.

4.4 conclusiones

El modelo no determinista para la auto-verificación de integridad pro-puesto, tiene como objetivo verificar la integridad de la componentede software protegida, a la vez que ofusca su comportamiento anteun ataque dinámico.

Las verificaciones de integridad se logran mediante una red deauto-verificación de integridad conformada por un componente dedetección y uno de respuesta. Un algoritmo de integración permiteque la red sea distribuida a lo largo del software a proteger, lográn-dose una una auto verificación redundante en tiempo de ejecución.

Los controles de integridad se realizan de forma no determinista,lo cual permite ofuscar el mecanismo de protección ante ataques di-námicos.

5M O D E L O PA R A L A E VA L U A C I Ó N D E L AS E G U R I D A D

Como se estableció en el capítulo 3 (epígrafe 3.5) resulta difícil reali-zar una evaluación cuantitativa y objetiva de la seguridad de un sis-tema en sentido general, por lo que no existe un consenso en cuantoal modelo a utilizar para esta evaluación. En particular el nivel segu-ridad que brinda un mecanismo de protección está determinado porel mínimo esfuerzo requerido por un atacante para violentarlo (Sch-neier, 1999). Sin embargo, la existencia de diversos factores no contro-lables y/o subjetivos, como pueden ser las habilidades del atacante,su experiencia en el manejo de herramientas o su nivel de motivación,hacen inviable la estimación de forma rigurosa de dicho esfuerzo, loque se suele denominar seguridad demostrable (provable security).

En la presenta investigación se aborda esta problemática desde elpunto de vista de la seguridad práctica, en contraposición a la segu-ridad demostrable, estableciendo un modelo escalable que permitaestimar el esfuerzo requerido por un ataque concreto sobre una redAVI que se ajuste a la propuesta. Este modelo combina la flexibili-dad del Árbol de Ataque con la capacidad descriptiva de la Teoría dela Información, permitiendo de esta forma adecuar el modelo a losdistintos tipos de ataque a la vez que se tiene en cuenta el no determi-nismo del mecanismo de protección. La propuesta ofrece una dobleestimación: el coste del ataque considerado y el nivel de ofuscaciónalcanzado por la protección.

De forma general, el capítulo está estructurado en dos secciones. Enla sección 5.1 se detalla el árbol de ataque propuesto. En la sección5.2 se propone un modelo basado en la teoría de la información parala evaluación del comportamiento no determinista de la propuesta

79

80 modelo para la evaluación de la seguridad

realizada. Por último, en la sección 5.3 se brindan las conclusionesparciales del capítulo.

5.1 árbol de ataque

La figura 18 muestra el árbol de ataque propuesto. Cada rama delárbol expone un conjunto de pasos que puede llevar a cabo el atacantepara desactivar de forma objetiva el mecanismo de protección.

Desactivar el mecanismo de

protección

Manipular nodos

Generar Casos de Prueba

Generar conjunto de

Casos de Prueba

Minimizar conjunto de

Casos de Prueba

Priorizar conjunto de

Casos de Prueba

andand

Localizar nodos

Comprobar manipulación

and and and

Modificar y observar respuesta

and

Construir oráculo de

prueba

Figura 18 Árbol de ataque del modelo de protección propuesto.

Este árbol de ataque permite evaluar el proceso de ingeniería in-versa descrito en el epígrafe 2.4.2, específicamente el subproceso demanipulación, en este caso aplicado al modelo de protección propues-to. Cabe destacar que sólo se contempla la localización de los nodosde protección mediante una inspección dinámica y se asume que elmecanismo propuesto es resistente ante análisis estáticos1, forzandoal atacante a realizar pruebas dinámicas ya sean funcionales (black-box testing) o estructurales (white-box testing).

El nodo raíz del árbol indica la desactivación total del mecanismode protección. El atacante habrá logrado este objetivo tras ejecutarcada uno de los procesos que se encuentran en el segundo nivel del

1 Esto supone que los nodos estarán debidamente diversificados y no es posible sulocalización mediante la búsqueda de patrones de estructuras de código similaresdentro del software.

5.1 árbol de ataque 81

árbol. Estos comprenden la generación de los casos de prueba, la lo-calización y manipulación de los nodos de la red AVI y por últimola comprobación de la eficacia del ataque. Para completar con éxitoestos procesos, se deben llevar a cabo un conjunto de tareas o ata-ques específicos, que son representados a partir del tercer nivel delárbol en adelante. Estos ataques son variables, dado que puede existirmás de una vía para lograr el mismo objetivo. La variabilidad en elataque está condicionada fundamentalmente por el conocimiento, ha-bilidades y herramientas que disponga el atacante. Por este motivo,el coste del ataque sobre el mecanismo de protección puede variar endependencia de la rama que se siga.

A continuación se realizará una descripción de posibles ataques detercer nivel, considerando sólo las ramas que menor coste imponganpara alcanzar el nodo raíz y descartando así los de mayor coste. Elárbol podrá ser modificado a partir del tercer nivel en la medida quese identifiquen nuevos tipos de ataques.

5.1.1 Generación de los casos de prueba

Inicialmente será necesario generar una cantidad suficiente de casosde prueba (test case)2 que permitan localizar, mediante un análisisdinámico, todos los nodos de la red de auto-verificación de integridadinsertada en el software bajo ataque.

En el caso más favorable para el atacante, el conjunto de casos deprueba garantiza una cobertura del 100 % del código. De otra formacualquier zona del código que haya quedado sin cobertura podríaalbergar un nodo o subconjunto de la red susceptible de activarsedurante la ejecución normal del software por parte de un usuario ile-gítimo. En la práctica, lo normal será que el atacante no dispongadel código fuente del software bajo ataque y además no esté fami-liarizado con la lógica de negocio del mismo. Estas circunstanciassupondrán un esfuerzo adicional a la tarea de generar el conjunto de

2 Caso de prueba: un caso de prueba es más general que un dato de prueba. Para uncaso de prueba se especifican las precondiciones y postcondiciones, además de losdatos de prueba. Por ejemplo, el caso de prueba puede comprender la definiciónuna variable de entorno antes de ejecutar una aplicación con un dato de prueba.


casos de prueba e impedirán que la cobertura sea máxima (Bardinand Herrmann, 2008, 2011).

En la industria, la generación de casos de prueba es, por lo gene-ral, un proceso manual, siendo una práctica extremadamente difícily costosa. Diversos autores (Kushwaha and Misra, 2008; Sharma andKushwaha, 2012) cifran entre un 50 y un 60 % el esfuerzo necesariodel total del proceso de desarrollo de software. Teóricamente, la ge-neración automatizada de casos (datos) de prueba es un problemaindecidible (McMinn, 2004). Por este motivo, actualmente existen dostendencias para automatizar las pruebas estructurales: (1) ejecuciónsimbólica dinámica (Li et al., 2009b; Majumdar and Sen, 2007; Sen,2007) y (2) pruebas basadas en búsqueda (McMinn, 2004). Muchosautores han planteado que estas dos técnicas brindan mejores resul-tados respecto otras, por ejemplo generación aleatoria, pero aplicadoa programas de pequeña escala. Resultados experimentales recientes(Lakhotia et al., 2009, 2010) muestran que estas técnicas aplicadas asoftware convencionales no superan el 50 % de cobertura de bifurca-ciones, por lo que el proceso debe concluirse de forma manual.

Hay estructuras de código en un software, relacionadas con la pro-pia lógica de negocio, que se ejecutan solamente para una pequeñaporción del dominio de los datos de entrada, denominándose en oca-siones código inalcanzable (Chou et al., 2011). Por este motivo, se ha-ce difícil lograr altos índices de cobertura de código para un softwaremás o menos complejo (McMinn, 2004). Por tanto, debe asumirse uncompromiso entre el coste total del ataque y el nivel de desprotecciónque se consigue.

Con el fin de conseguir minimizar el coste del ataque, puede serútil minimizar y priorizar el conjunto de casos de prueba.

Minimización el conjunto de casos de prueba

Dado el comportamiento no-determinista del mecanismo de protec-ción, el atacante debe ejecutar un número repetido de veces el softwa-re durante la localización de los nodos, y repetir el proceso para cadauno de los casos de prueba. Por este motivo puede ser de interéspara el atacante minimizar el conjunto de casos, eliminando funda-mentalmente aquellos que sean redundantes en cuanto a coberturade código.


Encontrar el conjunto mínimo de casos de prueba para garantizarel 100 % de cobertura de código es un problema NP-completo (Yooand Harman, 2010a,b), como caso particular del problema de cober-tura (Garey and Johnson, 1979) y por tanto el atacante tendrá queemplear técnicas heurísticas para minimizar el conjunto de datos deentrada, lo cual supone un esfuerzo adicional. Por este motivo, seminimizará el conjunto de casos de prueba solo cuando el esfuerzo(eficiencia) computacional sea menor al esfuerzo de analizar el soft-ware sin minimizarlo. De antemano se desconoce cuál proceso serámás costoso, por lo que no es posible saber si la minimización serárentable.

Priorización los casos de prueba

Establecer prioridad entre los casos de prueba tiene como objetivo or-ganizar los casos de forma que se maximice la detección de fallas. Eneste caso, la detección de fallas está referido a identificar una respues-ta del mecanismo de protección ante una modificación deliberada delatacante.

Para el atacante es suficiente que cada nodo de la red se ejecute almenos para un caso de prueba. La situación ideal sería que todos losnodos de verificación se ejecutasen con la menor cantidad de casosde prueba, lo que supone un menor esfuerzo en la localización. Poreste motivo, el atacante tendrá que priorizar los casos de prueba quemayor cobertura garanticen, lo que aumenta la probabilidad de que seejecuten más nodos por caso de prueba, a la vez que el caso de pruebase ejecute en menos tiempo. Para ello, el atacante se enfrentará a unproblema de optimización multiobjetivo (Maia et al., 2010; Yoo andHarman, 2007), en el cual se debe maximizar la cobertura de códigoy minimizar el tiempo de ejecución del caso de prueba.

Al igual que la minimización, se desconoce si el ataque será máseconómico al priorizar los casos de prueba por el esfuerzo que requie-re.


5.1.2 Localización de los nodos de la red

Una vez que se ha generado un conjunto de casos de prueba, es ne-cesario proceder a realizar un análisis dinámico del software paralocalizar cada uno de los nodos de verificación de la red.

Dependiendo del ataque, pueden existir diferentes variantes paralocalizar los nodos de la red. Estas variantes tienen en común que(1) los nodos son localizados a partir de las respuestas que brindael mecanismo de protección tras una modificación y (2) dado el nodeterminismo, se hace necesario ejecutar el software reiteradas vecespara obtener una respuesta.

Para detectar las respuestas, el atacante debe almacenar los paresentrada/salida generados por el software original para cada caso deprueba, esto es lo que se denomina construir un oráculo de prueba.El oráculo permite identificar cuándo una salida del software ha sidoerrónea para una entrada de datos, lo que evidencia una respuestadel mecanismo de protección. El atacante repetirá este proceso una yotra vez hasta localizar todos los nodos de la red.

Las actividades asociadas a la generación del oráculo de prueba y lalocalización de los nodos de verificación se describen a continuación.

Generación del oráculo de prueba

Dado que las respuestas brindadas por el mecanismo de protecciónpropuesto se basan en degradar el funcionamiento de la lógica denegocio del software, el atacante debe ser capaz de distinguir, paracada entrada de datos (caso de prueba), si la salida (respuesta) delsoftware es correcta o no tras una modificación.

Para conseguir esto es necesario ejecutar el software para cada unode los casos de prueba sin haber realizado modificación alguna so-bre este, almacenando el resultado de las salidas correspondientes.El conjunto de casos de prueba se representará por el conjunto E =

{e1, . . . , en}, donde ej se corresponde con un caso de prueba. Las sa-lidas del software se representan mediante el conjunto S = s1, . . . , snsiendo |S| = |E|.

El conjunto de pares ordenados de las correspondientes entrada-salida conforma el oráculo de prueba, que se define como Osoft =

{〈e1, s1〉, 〈e2, s2〉, . . . , 〈en, sn〉} para cada ei ∈ E y si ∈ S.


El algoritmo 4 describe la generación del oráculo de prueba.

Algoritmo 4: Algoritmo para generar el oráculo de prueba.entrada :E y Softsalida :O

1 O← ∅;2 for ei ∈ E do3 si ← Soft(ei);4 O← O∪ {〈ei, si〉};

El atacante sabrá que el mecanismo de protección ha emitido unarespuesta, cuando para un caso de prueba, el resultado que genera elsoftware modificado es distinto del que brinda el oráculo de pruebapara alguna ejecución del software.

Modificación y verificación de la respuesta

A continuación se exponen dos variantes de localización de los nodosde verificación, aunque no se descarta que puedan existir otras.

El algoritmo de depuración inversa puede resumirse en los siguientespasos (ver algoritmo 5):

1. Localizar los nodos correspondientes a cada objeto de la ve-rificación oi de la red asociados con la lógica de negocio delsoftware3, p. ej., la verificación de una licencia o condición deevaluación del software (tiempo, número de ejecuciones, etc.)

2. Manipular algún byte(s) del nodo actual de forma tal que se veaafectada la integridad, pero no se modifique la lógica de negociodel software. Inicialmente el nodo actual se corresponde con oi.

3. Para cada caso de prueba ej ∈ E, ejecutar el software hastaobtener una respuesta o el número de ejecuciones sea igual que

3 La localización de estos nodos es más fácil para el atacante respecto a los nodos deverificación, pues los primeros siempre dan una respuesta de forma deterministarelacionada con la lógica de negocio del software. Por ejemplo, el software emitemensajes del tipo “licencia no válida”, “período de prueba expirado”, “número má-ximo de ejecuciones alcanzado”, etc.


un umbral h. El valor del umbral h es fijado por el atacantey representa el compromiso entre coste del ataque y el gradode desprotección obtenido. Cuanto mayor es h mayor grado dedesprotección se obtiene (o mayor certidumbre en que el ataqueha sido exitoso) pero también se incurre en un mayor coste. Sino se obtiene respuesta y se llega al umbral para cada caso deprueba, el atacante asume que ha desactivado el mecanismo deprotección.

Algoritmo 5: Localización de los nodos mediante depuración in-versa.

entrada :Osoft = {〈e1, s1〉, 〈e2, s2〉, . . . , 〈en, sn〉}, h y Softsalida :Dir = {d1, . . . ,dn}

1 Dir← ∅;2 Obj← LocalizarObjetos();3 for oi ∈ Obj do4 nodo_actual← oi;5 while nodo_actual do6 respuesta← false;7 manipular nodo_actual;8 while (ej ∈ E) and (not respuesta) do9 count← h;

10 while (count 6= 0) and (not respuesta) do11 data← Soft(ej);12 if data 6= sj ∈ O then13 respuesta← true;14 r← LocalizarRespuesta(sj);15 proximo_nodo← DepuracionInversa(r);16 Dir← Dir∪GetDir(proximo_nodo);17 nodo_actual← proximo_nodo

18 count← count− 1;


4. Localizar el nodo respuesta rj que provocó la respuesta. A partirdel nodo respuesta, realizar una depuración inversa hasta elnodo de verificación que lo activó4.

5. Almacenar la dirección de memoria de inicio del nodo localiza-do en el conjunto de direcciones Dir = {d1, . . . ,dn}. Establecerel nodo localizado como nodo actual, y volver al punto 2.

La principal ventaja de este algoritmo es que la localización de unnodo, ya sea de objeto de verificación inicialmente o de verificaciónposteriormente, lleva directamente a localizar otro nodo de verifica-ción, así sucesivamente hasta localizar toda la red.

Como desventaja se identifica el consumo apreciable de memoriarelacionado con el proceso de depuración inversa5. Por otra partepara localizar un nodo de verificación, primero es necesario localizarel nodo de respuesta que fue activado.

Una alternativa es el algoritmo de particionado lógico del software quese puede resumir de la siguiente forma (ver algoritmo 6):

1. Dividir la sección de código del software en n particiones ló-gicas conformando el conjunto Part = {prt1, . . . ,prtn}. Cadaprti = {StartAddi,EndAddi} conforma una partición y los va-lores StartAddi y EndAddi indican las direcciones de memoriade inicio y fin de la partición i. Cada partición tendrá un ta-maño determinado (puede ser constante o no) y StartAdd0 =

dir_base_code_sec y StartAddi = EndAddi−1 + 1 para i > 1.

2. Para cada partición prti de forma independiente, manipular al-gún byte(s) de la partición prti, de forma tal que se vea afectadala integridad, pero no se modifique la lógica de negocio del soft-ware.

4 El atacante puede decidir eliminar los nodos respuesta en lugar de los nodos deverificación, sin embargo, la cantidad de nodos respuesta es mucho mayor y deberíaeliminarlos todos para asegurar la desactivación de la red. Por el contrario anulandolos nodos de verificación ya no es necesario eliminar los nodos respuesta.

5 Por ejemplo, para realizar una depuración de este tipo al navegador Mozilla, senecesita un procesador core i7, al menos 8 GB RAM y 256 GB de almacenamiento endisco.

https://developer.mozilla.org/En/Debugging/Record_and_Replay_Debugging_Firefox


3. Para cada caso de prueba ej ∈ E, ejecutar el software hastaobtener una respuesta o el número de ejecuciones sea igual queun umbral h. El valor del umbral h es fijado por el atacante.

4. Si se obtiene una respuesta, marcar la partición prti como quees verificada por el mecanismo de protección. Para ello, almace-nar el índice de la partición en el conjunto de índices Index =

{idx1, . . . , idxm}. Destacar que |Index| 6 |Part|. El atacante pue-de asumir que en esa partición se encuentra al menos un no-do de verificación. Por este motivo, deberá realizar un análisisestructural del código o los datos comprendidos dentro de lapartición para determinar si se corresponde con un nodo deverificación.

Este ataque tiene como ventajas que el atacante localiza directa-mente el nodo y no necesita llegar a este mediante una depuracióninversa a partir de los nodos respuesta. Por lo tanto, la cantidad denodos respuesta en este caso no influye en la seguridad del algoritmo.

Algoritmo 6: Localización de los nodos mediante particionado ló-gico del software.entrada :Osoft = {〈e1, s1〉, 〈e2, s2〉, . . . , 〈en, sn〉}, n, h y Softsalida : Index = {idx1, . . . , idxm}

1 Index← ∅;2 Part← GenerarParticiones(Soft, n);3 for prti ∈ Part do4 respuesta← false;5 manipular prti;6 while (ej ∈ E) and (not respuesta) do7 count← h;8 while (count 6= 0) and (not respuesta) do9 data← Soft(ej);

10 if data 6= sj then11 respuesta← true;12 Index← Index∪GetIndex(prti);13 count← count− 1;


Como inconveniente principal está el tamaño de la partición. Si eltamaño de la partición es muy grande, puede que el atacante modifi-que un byte(s) contenido en la partición, pero que no se correspondecon un nodo de verificación. Esto lo obliga a hacer más pequeña lasparticiones, lo cual no es deseable pues aumenta el número de parti-ciones y el tiempo del ataque. El atacante debe llegar a un consensoentre el número y el tamaño de las particiones; para particiones másgrandes, menos tiempo de ataque pero mayor es la incertidumbre desi la partición contiene o no un nodo, lo contrario ocurre con particio-nes pequeñas.

Independientemente del algoritmo de ataque empleado, si tras unnúmero determinado de ejecuciones para todos los casos de uso, elatacante no percibe respuesta alguna, se debe a:

1. Modificó una parte del software que no es verificada por el me-canismo de protección.

2. Modificó el/los nodo(s) de la red de auto-verificación que seencuentran desprotegidos.

3. No ha ejecutado el software con el conjunto de casos de pruebarequerido para que se ejecute: (1) el nodo que verifica la zonamodificada o (2) el nodo de respuesta que ha sido activado.

4. No ha realizado el número suficiente de ejecuciones para quese observar una respuesta, o sea, el umbral h es muy bajo.

Estos elementos hacen que el atacante crea o tenga la certeza deque ha desactivado el mecanismo de protección, cuando en realidadno es así.

Teniendo en cuenta los algoritmos 5 y 6, el peso del nodo “Mo-dificar y observar respuesta” en el árbol de ataque, se correspondecon el esfuerzo de aplicar alguno de estos algoritmos. Es necesariodestacar que en cualquier caso el esfuerzo estará directamente rela-cionado con el umbral h. Este umbral determina el número mínimode ejecuciones necesarias para observar una respuesta y guarda estre-cha relación con el no determinismo de la red. La estimación de esteumbral o al menos el establecimiento de una relación de precedenciaentre los umbrales asociados a distintas configuraciones de la red seabordará en el epígrafe 5.2 de este capítulo.


5.1.3 Manipulación de los nodos

Una vez que el atacante ha localizado la posición de los nodos de lared, tendrá que analizar su funcionamiento y modificarlo de formaadecuada para que no realice las verificaciones sobre su conjunto deverificación.

La complejidad de este proceso se estima de forma manual y de-pende de factores subjetivos tales como la habilidad del atacante, he-rramientas de que disponga, nivel de motivación, etc.

Dada el solapamiento de verificación entre los nodos, el atacante severá forzado a eliminar todos los nodos de la red. La única vía paraeliminar parcialmente la red de auto-verificación, es localizar el/losnodo(s) que se encuentren sin protección y desactivarlos. Esto provo-ca que existan nuevos nodos sin protección, por lo que el atacanterepetirá el proceso una y otra vez hasta desactivar toda la red.

5.1.4 Validación del ataque

Para finalizar es necesario comprobar la efectividad de la manipula-ción realizada. Para ello el atacante debe ejecutar de forma reiteradala aplicación para el conjunto de casos de prueba, y verificar que noexiste respuesta por parte del mecanismo de protección.

Si tras la manipulación de los nodos, el mecanismo de protecciónejecuta alguna respuesta, entonces el atacante no ha manipulado de-bidamente cada nodo, o ha quedado algún nodo por localizar. Deesta forma, se enfrenta en esta fase a problemas similares a la fase delocalización.

Para la validación del ataque (ver algoritmo 7), se utiliza un con-junto cuya cardinalidad es menor o igual a la del oráculo de pruebaO ′

soft ⊆ Osoft que activa todos los nodos de protección. El atacantehabrá obtenido dicho conjunto a partir de la localización de los no-dos (ver algoritmo 5 y 6). La conformación del subconjunto O ′

soft esposible dado que un mismo caso de prueba puede activar más de unnodo de verificación.

Para tener la certeza de que se han desactivado todos los nodos deforma apropiada, tendrá que ejecutar el software de forma reiterada


(umbral h) para cada caso de prueba perteneciente a O ′soft, en busca

de la activación de una respuesta.

Algoritmo 7: Validación de la manipulación.entrada :O ′

soft = {〈e1, s1〉, 〈e2, s2〉, . . . , 〈en, sn〉}, h y Softsalida : respuesta

1 respuesta← false;2 while (ej ∈ E) and (not respuesta) do3 count← h;4 while (count 6= 0) and (not respuesta) do5 data← Soft(ej);6 if data 6= sj then7 respuesta← true;

8 count← count− 1;

Si tras aplicar el algoritmo, la variable respuesta es falsa, el atacan-te puede asumir que:

1. Ha desactivado satisfactoriamente todos los nodos de la red deauto-verificación.

2. No ha ejecutado el software con el conjunto de casos de pruebarequerido.

3. No ha realizado el número suficiente de ejecuciones para quese pueda observar una respuesta.

Al igual que el proceso de localización, los puntos 2 y 3 hacenque el atacante no tenga total certeza de la efectividad del ataquerealizado. Esto implica que se deba incrementar el valor del umbral hpara tener mayor certeza de éxito, aumentando de esta forma el costedel ataque.

Un inconveniente de este algoritmo radica en el hecho de que elatacante no puede distinguir cuáles son los nodos que no han sidomanipulados correctamente por solo recibir una respuesta. Esto sedebe a que un mismo caso de prueba puede activar más de un nodode verificación. Por este motivo, el atacante debe identificar dichos


nodos por otra vía, manipularlos y repetir nuevamente el algoritmode validación.

5.2 evaluación del nivel de ofuscación de la red avi no

determinista

En la presente sección se brinda un modelo para la evaluación cuanti-tativa del nivel de fuga de información del mecanismo de protecciónpropuesto.

El nivel de fuga de información puede ser calculado mediante laevaluación cuantitativa del flujo de información (ver epígrafe 3.5.2).Esta evaluación no determina el límite de recursos requeridos (tiem-po, memoria, capacidad de cálculo, etc.) para violentar el mecanismode protección, pero si indica cuanta información sensible se filtra deeste. En sentido general, mientras menos cantidad de información sefugue del mecanismo de protección, más ejecuciones debe realizar elatacante para alcanzar el nivel de información requerido para corro-borar su ataque.

De esta forma, la fuga de información puede ser considerada co-mo una métrica para evaluar el nivel de ofuscación del mecanismo deprotección propuesto y que estará directamente relacionado con elumbral h definido en el anterior epígrafe. Mientras menor sea la fugade información, mayor será el nivel de ofuscación alcanzado.

En los siguientes epígrafes se expone un modelo para el cálculode la fuga de información del mecanismo propuesto, basado en unataque dinámico del software6.

5.2.1 Cálculo de la fuga de información

Sea A la variable aleatoria discreta con alfabeto A = {e, f} que repre-senta el éxito (e) o fracaso (f) de un ataque sobre un nodo de la red deauto-verificación, durante un análisis dinámico del software por partede un atacante. El ataque en este caso se refiere tanto a la localizaciónde un nodo, como a la comprobación del éxito de una manipulacióndel mismo.

6 No se calcula cuanta información se fuga del mecanismo de protección ante unanálisis estático, pues la propuesta se centra, esencialmente, en un análisis dinámico.

5.2 evaluación del nivel de ofus . de la red avi no determinista 93

La función de densidad de probabilidad p(a) = P(A = a), a ∈ A

describe la probabilidad de llevar a cabo un ataque exitoso o fallido.Si el atacante cree que su ataque ha sido exitoso, entonces p(e) = 1.Por el contrario, si p(f) = 1 el atacante habrá considerado que elataque ha sido un fracaso. Un valor de p(e) = p(f) = 0.5 indica unaduda respecto a un ataque exitoso o fallido con igual probabilidad deocurrencia. La variable aleatoria A toma los siguientes valores:

A =

e con probabilidad p

f con probabilidad 1− p(18)

Por otro lado, se tiene la variable aleatoria discreta R con alfabetoR = {r, r} que representa la respuesta (r) y no respuesta (r) del me-canismo de protección ante una modificación, en cada ejecución delsoftware. Esta variable depende de los valores de probabilidad quetome la variable A.

El ataque sobre un nodo se considera un fracaso (f ∈ A), cuandoel atacante nunca recibe respuesta alguna (r ∈ R) con alto grado decerteza por parte del mecanismo de protección. Se considera un ata-que exitoso (e ∈ A) cuando el mecanismo de protección emite unarespuesta (r ∈ R) con una determinada probabilidad tras una modifi-cación de dicho nodo.

La relación entre A y R se expresa a partir del canal de informaciónde la figura 19, caracterizado por las probabilidades condicionalesP(ri|ai) de las entradas A y las salidas R.

Figura 19 Canal de información del ataque sobre un nodo.


El canal de información queda definido completamente por las pro-babilidades de los símbolos de entrada p(e), p(f) y su matriz de pro-babilidades condicionales:

P =

[P(r|e) P(r|e)

P(r|f) P(r|f)

]=

[P11 P12

P21 P22

]=

[1− p p

0 1

](19)

La noción de fuga de información puede ser relacionada con elconcepto de información mutua de un canal de información; esto es,la reducción de la incertidumbre (entropía) sobre las entradas, unavez que se hayan observado las salidas, o sea, qué tanta informaciónsobre las entradas se gana tras observar las salidas.

La fuga de información puede definirse entonces como la diferen-cia entre la probabilidad de error a priori (antes de observar las sali-das) y a posteriori (tras observar las respuestas), que no es más quela información mutua de las entradas y salidas del canal; en este casoA y R respectivamente.

A menor valor de la información mutua I(A;R) (ver sección 3.5.2de la página 52), menor será la cantidad de información sensible quese filtra del mecanismo de protección. Esto es, mientras menor sea elvalor de I(A;R), en menor grado será la reducción de la incertidum-bre del atacante sobre el resultado del ataque A, una vez que conozcalas respuestas R emitidas por el mecanismo de protección.

En el anexo B se muestran los resultados de calcular la informaciónmutua I(A;R) de un nodo, para diferentes distribuciones de probabi-lidad a priori de las entradas al canal (ataque) con valores de p(e)entre 0 y 1. Igual rango de probabilidad p7 es asignado a la matrizdel canal.

En la figura 20 se puede apreciar la tendencia del valor de la in-formación mutua I(A;R) para los cálculos realizados. Los valoresmás altos de I(A;R) se obtienen para valores bajos de probabilidad(0 6 p 6 0.1) de no obtenerse una respuesta cuando el ataque ha sidoexitoso P(r|e), a la vez que la incertidumbre del éxito del ataque p(e)está próxima a 0.5.

7 p = P12 = P(r|e).


00.1

0.20.3

0.40.5

0.60.7

0.80.9

1 00.1

0.20.3

0.40.5

0.60.7

0.80.9

1

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

p(e)

p

I(A

;R)

(a)

p

p(e)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.00

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

(b)

Figura 20 Cálculo de I(A;R) para diferentes valores de p(e) y p.

En sentido general, el valor I(A;R) será más pequeño, tendiendo acero, para valores altos de probabilidad (0.9 6 p 6 1) de no obtenerseuna respuesta r para un ataque exitoso, a la vez que el nivel de certezasobre la eficacia del ataque es alto. Por ejemplo, el valor más pequeño


(distinto de cero) registrado en el cálculo de I(A;R) en la tabla 19 es0.014 bits, cuando p = 0.9 y p(e) = 0.9.

Intuitivamente, si el atacante está confiado de que su ataque es efec-tivo y la probabilidad de no emitirse una respuesta es alta, le bastarásolamente con realizar unas pocas ejecuciones para estar seguro quesu ataque es efectivo, cuando potencialmente no lo es.

Una mayor cautela del atacante durante la localización y compro-bación de la manipulación de los nodos, trae como consecuencia unnúmero mayor de ejecuciones. De esta forma, la certeza o nivel de cer-tidumbre del atacante sobre el éxito de su ataque aumenta a medidaque realiza un número mayor de ejecuciones, o sea para valores altosdel umbral h, definido en el árbol de ataque.

Los valores de I(A;R) = 0 se obtienen debido a:

1. La certeza del éxito (p(e) = 1) o fracaso (p(e) = 0) del atacantees total, sin importar la probabilidad con que se emita una res-puesta. El atacante no puede reducir la incertidumbre sobre laeficacia de su ataque cuando tiene total certeza de su valor. Estoimplica que no necesita comprobar el resultado de su ataque,bien porque está convencido que ha sido un éxito o un fracasorotundo.

2. La probabilidad de que se emita una respuesta es 0, indepen-dientemente del nivel de certeza del atacante. Este es el caso delos sistemas tolerantes a fallos (Anckaert et al., 2007; Chang andAtallah, 2002; Jakubowski et al., 2009), que en lugar de emitiruna respuesta, toleran el ataque de forma determinista.

En el siguiente epígrafe se definen los límites inferior y superior dela cantidad de información que se fuga del mecanismo de proteccióntras el ataque a cada nodo de verificación.

5.2.2 Métrica de ofuscación

El límite inferior de la cantidad de fuga de información se correspon-de con el valor I(A;R) = 0, o sea, que no existe fuga informaciónsensible del mecanismo de protección. Este es el caso ideal en el queexiste una independencia estadística entre los ataques y las respues-tas.


Por otra parte, el límite superior de la fuga de información paraun nodo se corresponde con la capacidad del canal C, que es pordefinición el valor máximo de información mutua8:

C = maxp(x)

I(A;R) (20)

Para una red de n nodos de verificación, el límite superior de fugade información es:

CM =

n∑i=1

Ci (21)

A partir de las especificaciones de los niveles inferior y superior defuga de información, el nivel de fuga de información para una red sedefine como:

F =

n∑i=1

I(A;R)i; 0 6 F 6 CM (22)

Donde I(A;R)i es la información mutua (fuga de información) paraun nodo i de la red.

5.2.3 Estimación del umbral de ataque

El no determinismo del modelo de auto-verificación propuesto, es-tá destinado fundamentalmente a retardar la localización y compro-bación de la manipulación sobre cada uno de los nodos de la redpor parte del atacante. Esto es posible porque un análisis dinámicode un software no determinista, suele ser mucho más complejo queun software determinista (Gromov et al., 2008; Guderlei et al., 2007;Nachmanson et al., 2004; Vain et al., 2007).

Para llevar a cabo un análisis dinámico sobre este tipo de sistemas,es necesario conocer de antemano cuál es la distribución de probabi-lidad que sigue el comportamiento no determinista del software en

8 Para p =0 (comportamiento determinista) y una entrada equiprobable p(e) =0.5, lacapacidad del canal es C =1 bit de información.


cuestión, así como los parámetros que caracterizan a dicha distribu-ción.

En el epígrafe anterior, se demostró que para altas probabilidadesde no emitirse una respuesta, el atacante recibe menos informacióndel mecanismo de protección, apenas sin importar el nivel de certezaque tenga sobre la eficacia de su ataque. Esto justifica por qué en losalgoritmos 5, 6 y 7, el atacante debe ejecutar el software de formareiterada hasta observar una respuesta o alcanzar el umbral h paracorroborar la efectividad de su ataque.

Este umbral está definido por una distribución de probabilidad geo-métrica que caracteriza el comportamiento no determinista.

Una variable aleatoria discreta H sigue una distribución geométricade probabilidad9 si, pruebas independientes repetidas pueden tenercomo resultado un éxito con probabilidad p y un fracaso con proba-bilidad 1− p y el número de la prueba h en el que ocurre el primeréxito es:

P(H = h) = p(1− p)h−1, h = 1, 2, 3, . . . (23)

La función de distribución geométrica acumulada (Cumulative Dis-tribution Function (CDF)) de H es:

P(H 6 h) = 1− (1− p)h, h = 1, 2, 3, . . . (24)

La media y la varianza de la variable aleatoria H con distribucióngeométrica es µ = 1

p y σ2 = 1−pp2 respectivamente.

Para el atacante, el éxito se corresponde con la observación de unarespuesta por parte del mecanismo de protección tras la realizaciónde una manipulación. Las pruebas realizadas son independientes en-tre sí, dado que el canal de información modelado es un canal dememoria nula, por lo que la probabilidad de aparecer un símbolo ala salida del canal no depende de la aparición de símbolos previos.

Para la evaluación de la seguridad del modelo propuesto, es ne-cesario conocer cuál es el número de ejecuciones h requeridos paraobtener una respuesta con un nivel de probabilidad R10.

9 De forma experimental, para determinar si un conjunto de datos sigue una distribu-ción teórica de probabilidad geométrica, es necesario realizar una prueba de bondadde ajuste de chi-cuadrado (chi-square goodness-of-fit test).

10 En teste caso, R puede ser visto como el nivel de confianza que tiene el atacante deobtener una respuesta. Para un nivel de confianza del 99 %, R toma valor 0.99.


El número de ejecuciones h puede ser calculado mediante la fun-ción cuantil (Gilchrist, 2000, epígrafe 7.7) F−1(r) de la variable H, parar ∈ (0, 1):

h = F−1(r) =

⌈ln(1− r)ln(1− p)

⌉(25)

Dado que la variableH sigue una distribución discreta, la expresióndxe significa redondear x al entero menor más cercano > x. Mientrasmás pequeño sea el valor de p, mayor será el número de ejecucionesh como promedio que tiene que realizar el atacante para obtener unarespuesta. Para el caso determinista p=1, h toma valor 1.

Por citar un ejemplo, si se desea conocer con un nivel de confianza99 % cuál es el número de ejecuciones que debe realizar un atacantepara obtener una respuesta ejecutada con probabilidad 0.001, segúnla ecuación 25:

h =

⌈ln(1− 0.99)ln(1− 0.001)

⌉= d4605.17e = 4606

El atacante deberá ejecutar el software un total de 4606 veces paraobtener una respuesta. En la figura 21 se muestra, para distintos va-lores de h, cuál es nivel de confianza que se tiene en observar unarespuesta, dado distintos valores de probabilidad.

100%100% %99%

80%

90%

100%

70%

80%

anza

p=0.01

50%

60%

de confia

37%30%

40%

Nivel d

p=0 001

10%

20%p=0.001

p=0.0001

0%

120

040

060

080

000

020

040

060

080

000

020

040

060

080

000

020

040

060

080

000

020

040

060

0

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46

h

Figura 21 Certeza de umbral de ataque para distintas probabilidades de res-puesta.


Para p = 0.01, bastan 2200 ejecuciones para tener un 100 % de con-fianza de observar una respuesta. Sin embargo, para las 4606 ejecu-ciones calculadas en el ejemplo anterior (p = 0.001), sólo se tiene un37 % de confianza para una probabilidad p = 0.0001.

5.3 conclusiones

En este capítulo se ha presentado un modelo para la evaluación de laseguridad del mecanismo de protección propuesto.

El modelo permite calcular el coste de un ataque exitoso sobre unaimplementación concreta del mecanismo de protección mediante unárbol de ataque.

Se definieron un conjunto de ataques generales que siempre debenser ejecutados. Al llevar a cabo de forma efectiva cada uno, se lograel objetivo final de desactivar el mecanismo de protección y en conse-cuencia, se puede calcular el coste asociado al ataque.

Para cada ataque general, se propuso un conjunto de ataques es-pecíficos, los cuales pueden ser variables y su identificación dependefundamentalmente de las habilidades e ingenio del atacante.

Adicionalmente, se propuso una métrica que permite estimar laofuscación alcanzada por el mecanismo de protección, al evaluar elnivel de fuga de información del mismo durante un ataque.

6I N F R A E S T R U C T U R A PA R A L A P R O T E C C I Ó N D ES O F T WA R E

El presente capítulo se realiza la propuesta de una Infraestructurapara la Protección de Software. Esta propuesta contempla el ciclo devida de un componente de protección, así como su integración en elproceso de desarrollo de software.

El objetivo general de la Infraestructura es abaratar el coste de desa-rrollo y automatizar el despliegue de los mecanismos de protección.De esta forma, las fábricas de software pueden incorporar los me-canismos de protección en sus productos, sin incurrir en un costesignificativo adicional.

En la sección 6.1 se enuncian la definición y los requisitos de laInfraestructura, además de una vista general de su organización. Pos-teriormente, en la sección 6.2 se enumeran los servicios que ofrecede cara a las empresas de desarrollo de software. Aspectos relaciona-dos con los componentes y procesos que conforman la infraestructurapueden ser vistos en las secciones 6.3 y 6.4 respectivamente. En la sec-ción 6.5 se describe la implementación parcial de la Infraestructura,que brinda un servicio de protección automatizado para el control deintegridad a través del modelo de AVI propuesto en el capítulo 4. Porúltimo se enuncian las conclusiones del capítulo en la sección 6.6.

6.1 definición y requisitos

A modo de definición, una Infraestructura para la Protección de Soft-ware (Software Protection Infrastructure, SPI) es una infraestructuraque provee servicios de protección a las aplicaciones y está conforma-da por componentes, servicios y procesos.

101

102 infraestructura para la protección de software

Los requisitos generales que pretende contemplar la propuesta deSPI son:

1. Automatización. El proceso de protección de software debe sertotalmente automatizado, requiriendo una intervención mínimapor parte del desarrollador de software, salvo para algunos ele-mentos de configuración. La automatización permite a su vez laespecialización, la compartimentación y la reutilización del procesode protección. La base de la propuesta de SPI radica en la utili-zación de un compilador extendido como principal motor de laautomatización del proceso de protección (ver figura 26).

2. Especialización y Compartimentación. Con estos requisitos sepersigue garantizar la preservación de la propiedad intelectualen ambos sentidos. Por un lado, el desarrollador de softwarepuede centrarse en la lógica de negocio de la aplicación sin ne-cesidad de comprender los algoritmos de protección, evitandoerrores de implementación (Wurster and van Oorschot, 2008).Por otro lado, los desarrolladores de componentes de protecciónno necesitan comprender la lógica de negocio de la protecciónpara desplegar el mecanismo de protección.

3. Reutilización. La reutilización permite que los componentes deprotección desarrollados puedan ser empleados para protegermúltiples aplicaciones sin ningún coste de tiempo y recursoshumanos adicionales. Por el contrario, si el proceso de protec-ción fuera manual, el coste se multiplicaría por cada software aproteger.

4. Escalabilidad y personalización. La escalabilidad permite queel mecanismo pueda ser desplegado de forma sencilla indepen-dientemente de la complejidad y tamaño del software, garanti-zando a la vez la viabilidad de su mantenimiento. Los compo-nentes de protección son desarrollados y actualizados de formacentralizada y luego distribuidos de forma personalizada a cadauno de los desarrolladores de software según sus necesidades.De esta forma, cada producto final dispondrá de un mecanismode protección propio y diferente del resto.

6.1 definición y requisitos 103

5. Flexibilidad en la comercialización. El mecanismo de protecciónno debe imponer restricciones que obstaculicen la comercializa-ción del software protegido, ya sea mediante soporte físico dealmacenamiento o por Internet.

De forma general, la propuesta de SPI está conformada por:

• Servicios. La SPI provee diferentes servicios para la protecciónde software, tales como resistencia a manipulación e inspecciónde software, autenticidad, anti-copia, detección de violaciones,entre otras.

• Componentes. Son las entidades, sistemas o subsistemas, queconforman la SPI.

• Procesos. Describen el funcionamiento coordinado de los com-ponentes de la SPI, así como la interacción con las entidadesfinales (las fábricas de software).

Una vista general de la SPI puede ser vista en la figura 22.

Entidad para el diseño de algoritmos de protección

Sistema de gestión de algoritmos de

protección

Repositorio de algoritmos de

protección

Diseñadores de algoritmos de protección

Entidad para el desarrollo de componentes de protección

Sistema de gestión de

componentes de protección

Desarrolladores de componentes de

protección

Repositorio global de

componentes de protección

Entidad para la gestión de protecciones

Sistema de gestión de protección de

Software

Entidad Final

Repositorio local de mecanismos de protección

Desarrolladores de software

Repositorio global de mecanismos de

protección

Internet

Sistema para el monitoreo de violación deprotecciones

Figura 22 Infraestructura para la protección de software.


En la entidad para el diseño de los algoritmos de protección, selleva a cabo el diseño y desarrollo de estos algoritmos por parte deespecialistas en protección. Todo el proceso de diseño es gestionadopor un sistema para este fin y los algoritmos son almacenados en unrepositorio de la entidad.

Estos algoritmos son consumidos directamente por la entidad en-cargada del desarrollo de los componentes de protección. Cada algo-ritmo es implementado en un componente de protección por desarro-lladores de software especializados en el desarrollo de compiladores.Esta especialización es requerida precisamente porque la automatiza-ción del proceso de protección de software es llevado a cabo por uncompilador. El proceso de gestión de los componentes de protecciónes realizado a través de un sistema y los componentes son almacena-dos en un repositorio de la entidad.

A partir de los requisitos de seguridad de una entidad final, queno es más que una fábrica de software que desea proteger sus pro-ductos, se configura un mecanismo de protección a la medida confor-mado por uno o varios componentes de protección. Este proceso selleva a cabo en la entidad encargada de la gestión de mecanismos deprotección, los cuales quedan almacenados en un repositorio globalde mecanismos de protección. Adicionalmente, esta entidad disponede un sistema para el monitoreo y gestión de las violaciones de lasprotecciones.

Por último, desde la entidad final, los mecanismos de protecciónsolicitados pueden ser descargados hacia un repositorio local. Estosmecanismos son empleados por una plataforma de protección parainsertar, de forma automatizada, el mecanismo de protección en elsoftware que se desea proteger.

6.2 servicios

A continuación se describen los principales servicios de protecciónproveídos por la SPI. Cada servicio, con excepción de la detección deviolaciones, es suministrado a la entidad final a través de los meca-nismos de protección.

6.2 servicios 105

Integridad de software

Servicio destinado a ofrecer resistencia ante la manipulación de unsoftware. Se garantiza en cierta medida que las aplicaciones protegi-das no puedan ser inspeccionadas con el fin de revelar su funciona-miento interno.

Privacidad de software

Con este servicio se ofrece resistencia ante la inspección de un softwa-re. Se garantiza en cierta medida que las aplicaciones protegidas nosean inspeccionadas por un atacante y por tanto evitar que se revelesu funcionamiento interno.

Diversidad de software

Este servicio permite la distribución de aplicaciones equivalentes fun-cionalmente, pero diferentes desde el punto de vista estructural, acada usuario final. Con esto se mitiga el impacto de la piratería desoftware, así como de vulnerabilidades.

Autenticidad

Con este servicio se garantiza la autenticidad de un software, verifi-cando que sea íntegro y haya sido emitido por la entidad autorizada.Con esto se garantiza además el derecho de autoría y propiedad inte-lectual de software.

Anti copia

Servicio destinado a evitar que el software comercializado sea du-plicado de forma no autorizada e indiscriminada por un atacante ousuario ilegítimo.

Detección de violaciones

Se detectan las posibles violaciones de aplicaciones protegidas con elobjetivo de detectar los componentes de protección comprometidospor un atacante.


6.3 componentes

A continuación se muestran los principales componentes que confor-man la SPI:

• Mecanismo de Protección.

• Plataforma de Protección.

• Entidad para el diseño de algoritmos de protección. Incluye elRepositorio de algoritmos de protección.

• Entidad para el desarrollo de componentes de protección. Inclu-ye el Repositorio global de componentes de protección.

• Entidad para la gestión de protecciones. Incluye el RepositorioGlobal de mecanismos de protección y el Sistema para el moni-toreo de violación de protecciones.

• Entidades finales de la SPI. Son las fábricas de software queconsumen los servicios proveídos por la SPI. Incluye Reposito-rio local de mecanismos de protección.

• Componentes de soporte. Componentes que sirven de soportea la infraestructura, tales como Listas de Revocación de Compo-nentes de Protección (LRCP), protocolos de comunicación (entrecomponentes de la SPI y entidades finales), elementos de audi-toría, etc.

6.3.1 Mecanismo de protección

Antes de describir directamente que es un mecanismo de protecciónen el contexto de una SPI, es necesario definir los siguientes elemen-tos:

• Algoritmo de protección. Algoritmo que especifica el análisis ylas transformaciones necesarias para proteger un software.

• Técnica de protección. Elemento conceptual que clasifica o agru-pa los distintos Algoritmos de Protección acorde al servicio deseguridad proveído. La tabla 1 muestra las principales técnicas

6.3 componentes 107

de protección existentes, así como el servicio de seguridad quepuede garantizar.

• Componente de protección. Es la implementación de un Algo-ritmo de Protección para un lenguaje de programación, sistemaoperativo y arquitectura de hardware específico.

De esta forma, un mecanismo de protección está compuesto por va-rios componentes de protección, seleccionados de forma tal que pue-dan satisfacerse los requisitos (servicios) de seguridad solicitados porla entidad final para un producto específico. Los componentes de pro-tección pertenecientes a un mecanismo de protección son aplicados alsoftware a proteger en un orden determinado, conformando una “co-la de protección”. Este orden está condicionado fundamentalmentepor la lógica del mecanismo de protección, por ejemplo, puede no serrazonable insertar una marca de agua después de cifrar un software.

El mecanismo de protección de un software puede ser distinto deotro, pues los requisitos de seguridad pueden variar y se puedenemplean distintos componentes de protección. Aún cuando los re-quisitos de seguridad sean los mismos, el mecanismo de proteccióndestinado a proteger un software puede ser distinto de otro. Esto per-mite que al violarse un mecanismo de protección específico, se veaafectado el menor número posible de instancias de la aplicación, dis-minuyendo el impacto del ataque.

Técnica de protección Servicio de seguridad asociado

Ofuscación Privacidad, Diversidad

Marcas de Agua Autenticidad, Integridad

Cifrado Privacidad

Diversidad de código Diversidad

Software resistente amanipulación

Integridad

Protección basada enhardware

Integridad, Privacidad, Autenticidad

Tabla 1 Técnicas de protección.


La figura 23 muestra un diagrama de clase con las relaciones entreestos elementos. Los requisitos de seguridad, que se satisfacen a par-tir de los servicios de seguridad brindados por la SPI, son obtenidosa partir de un modelo de amenaza (Saini et al., 2008) realizado por elanalista de seguridad del grupo de desarrollo de software.

Mecanismo de protección

Componente de protección

Plataforma de protección

Técnica

Modelo de amenaza

Algoritmo

Auto−verificación

Requisito

Marca de Agua Ofuscación

Diversidad

Software

Cifrado

implementa 11

usa

1..*

1..*

1..*

0..*

usa0..*

1

satisface

1..*

1

protege

1..*1..*

usa0..*

1

especifica

1..*1..*

realiza

1

1..*

Figura 23 Diagrama de clases del Mecanismo de Protección.

6.3.2 Plataforma de Protección

El Mecanismo de Protección es aplicado a un software mediante laPlataforma de Protección, obteniéndose como resultado un softwareprotegido. En esta propuesta, la plataforma de protección se basa enla extensión de las funcionalidades de un compilador, agregando unanueva fase de compilación durante la cual se integra el mecanismode protección.

Teniendo en cuenta que la cantidad de código de protección a inser-tar en el software puede ser grande, será necesario invertir un tiempoconsiderable en dicho proceso, aumentado las horas/hombre en eldesarrollo de proyecto de software. Este coste se multiplica ademáspor cada software a proteger.

Este proceso puede ubicarse en tres fases diferentes durante la com-pilación del software:

6.3 componentes 109

1. Pre-compilación. Las transformaciones se realizan directamen-te sobre el código fuente del software antes de ser compilado,dando como resultado un código fuente protegido. En este ni-vel se requiere transformar el código fuente (cadena literal decaracteres) en una estructura que permita acceder a cada unode sus elementos, por ejemplo los métodos, variables, instruc-ciones, operadores etc.

2. Compilación. Las transformaciones se llevan a cabo sobre unarepresentación intermedia del código fuente durante el proce-so compilación. En este nivel se cuenta con una estructura delcódigo que permite el acceso a cada uno de sus elementos.

3. Post-compilación. Las transformaciones se realizan sobre soft-ware ya compilado, o sea sobre el código máquina resultantedel proceso de compilación para una arquitectura de hardwareespecifica.

La selección del nivel donde se aplique la protección está condi-cionada fundamentalmente por la dependencia del lenguaje de pro-gramación en el cual esté desarrollado el software a proteger y de laarquitectura del procesador hacia la cual será compilado.

Se puede desarrollar una herramienta que permita automatizar laprotección de un software para un lenguaje o arquitectura de proce-sador específico, pero esto restringirá el alcance de la herramienta,limitando su uso a determinados contextos. La tabla 2 muestra deforma resumida la dependencia en ambos sentidos para cada uno delos niveles en el cual se puede aplicar la protección.

Lenguaje Arquitectura

Pre-compilación si no

Compilación no no

Post-compilación no si

Tabla 2 Dependencia del lenguaje y arquitectura.

En la fase de pre-compilación, existe una independencia de la ar-quitectura del procesador, pero se requiere de un soporte adicional


para manejar la gramática de cada uno lenguajes de programación.Lo contrario ocurre en post compilación, en el cual no es necesariomanejar las especificaciones del lenguaje de programación, pero si laarquitectura de los diferentes procesadores.

La mejor opción se encuentra durante la fase de compilación. En es-ta fase se cuenta con una representación intermedia, ajena al lenguajede programación o de la arquitectura del procesador.

Para evitar la implementación de varias plataformas, se puede em-plear un compilador que soporte varios lenguajes de programación yarquitecturas de hardware. Tal es el caso del compilador GCC1 (GNUCross Compiler) o el Clang2 (perteneciente a la infraestructura LLVM),que al ser de código abierto, permiten su extensión.

6.3.3 Entidad para el diseño de algoritmos de protección

Entidad responsable de llevar a cabo el diseño de los algoritmos deprotección en la SPI.

El objetivo de esta entidad es centrarse en el diseño de los algo-ritmos de protección, no en su implementación. Al separar el diseñode la implementación, se alcanza un mayor grado de especializacióndentro de la infraestructura, lo que permite acortar el tiempo de desa-rrollo de los componentes de protección.

Los algoritmos de protección son agrupados según la técnica deprotección que realizan, pero a su vez, cada técnica posee su propiaclasificación o subtécnica (por ejemplo, véase (Mavrogiannopouloset al., 2011) para el caso de auto-modificación y (Nagra et al., 2002)para marcas de agua). Esto implica que, bajo una misma categoría deuna técnica, pueden existir varios algoritmos de protección. Para unamisma clasificación, todos los algoritmos de protección deben cum-plir con una “interfaz” única, lo cual permite emplear indistintamen-te un algoritmo u otro al conformar nuevos algoritmos o mecanismosde protección.

Un algoritmo de protección puede incluir en su diseño otros algo-ritmos de protección que lo complementan para alcanzar el grado deseguridad requerido, por ejemplo, en el diseño del algoritmo de auto-

1 http://gcc.gnu.org/

2 http://clang.llvm.org/

http://gcc.gnu.org/

http://clang.llvm.org/

6.3 componentes 111

verificación de integridad propuesto, se requiere que los nodos deverificación estén diversificados, por lo que se emplea un algoritmode diversificación.

El diseño de los algoritmos de protección es llevado a cabo por unpersonal especializado, tanto en ataque como en defensa de software.Los diseñadores de algoritmos de protección dominan las técnicasde protección de software existentes y los tipos de ataques medianteingeniería inversa.

Los algoritmos de protección pueden ser especificados mediantepseudo-código, modelos, descripciones literales, etc. que permitan suadecuada descripción para su posterior implementación. Las especi-ficaciones son almacenados en un repositorio (ver figura 22), el cualpuede ser accedido mediante un sistema de gestión de algoritmos deprotección. Entre las principales funciones se encuentra:

1. Gestión de los algoritmos de protección. Comprende la adición,actualización y eliminación de algoritmos de protección por par-te de los diseñadores.

2. Publicación de algoritmos de protección. Se publican los algorit-mos acorde a una técnica y sub-técnica determinada. Se brindanfuncionalidades de búsqueda. Se especifica si los algoritmos dis-ponen de una implementación concreta.

Si un algoritmo, implementado en un componente de proteccióny aplicado a un software, es violentado por un atacante, entonceses necesario reconsiderar su diseño con el objetivo de fortalecer loselementos débiles que provocaron su violación.

6.3.4 Entidad para el desarrollo de componentes de protección

Entidad encargada de implementar un algoritmo de protección pre-viamente diseñado. El resultado de la implementación del algoritmo,es el componente de protección.

Los componentes de protección son desarrollados por personal es-pecializado en el desarrollo de software, especialmente en desarro-llo de compiladores. Un desarrollador de componentes de protecciónestá familiarizado en menor grado con las técnicas de protección y


ataque mediante ingeniería inversa respecto al diseñador de algorit-mos de protección. Esto permite que se centre en la implementacióndel componente, sin entrar en detalles que cuestionen el diseño delalgoritmo, a menos que exista una restricción que impida su imple-mentación.

A través del sistema de gestión de algoritmos de protección, losdesarrolladores de componentes de protección pueden acceder a losalgoritmos de protección publicados y proceder a su implementación.

Es necesario destacar que un componente de protección implemen-ta un solo algoritmo de protección y viceversa. Dado que un algorit-mo de protección puede emplear otros algoritmos en su diseño, en-tonces un componente de protección puede depender de otros com-ponentes para su correcto funcionamiento.

Los componentes de protección son almacenados en el reposito-rio global de componentes de protección, el cual puede ser accedidoa través del sistema de gestión de componentes de protección. Lasprincipales funcionalidades del sistema son:

1. Gestión de los componentes de protección. Comprende la in-serción, actualización y eliminación de Componentes de Protec-ción en el repositorio.

2. Publicación de componentes de protección. Se publican los com-ponentes acorde a la entidad final para la cual fue emitido. Sebrindan funcionalidades de búsqueda.

Una vez implementados, los componentes de protección son pro-bados desde el punto de vista funcional y de seguridad. Se realizaun proceso de prueba en el cuál son sometidos a ataques, softwarede prueba protegidos con dichos componentes, con la intención dedetectar posibles fallas de seguridad. La falla puede correspondersecon un error en la implementación del componente o en el diseño delalgoritmo. En cada caso, la entidad correspondiente procede a solu-cionar la falla detectada por el equipo de prueba. Este equipo debeestar especializado en ataque de software mediante ingeniería inver-sa, y constituyen un primer nivel de prueba y retroalimentación a losdiseñadores de algoritmos de protección, lo que permite una mejoracontinua y calidad del proceso.

6.3 componentes 113

Es necesario destacar que el componente de protección liberadopara una entidad final no puede ser usado por otra entidad.

6.3.5 Entidad para la gestión de protecciones

Es la entidad encargada de gestionar las solicitudes de las entidadesfinales para brindarles los servicios de protección de software reque-ridos.

Las solicitudes de los distintos servicios de protección de las enti-dades finales son gestionadas a través del sistema de gestión de pro-tección de software. Dichas solicitudes, se hacen corresponder con loscomponentes de protección necesarios para conformar el mecanismode protección que satisfaga la solicitud. Esto para cada solicitud enparticular de cada entidad final. La entidad para la gestión de pro-tecciones, solicita a la entidad para el desarrollo de componentes deprotección, que genere los componentes de protección a nombre dela entidad final que lo solicitó. Tanto las solicitudes, como los meca-nismo de protección correspondientes, son almacenados en el reposi-torio de mecanismo de protección.

Un elemento significativo en la SPI es el sistema para el monitoreode violación de protecciones. A través de este sistema, se gestionanlas incidencias de posibles violaciones de las aplicaciones protegidascon los componentes de protección. Esto permite, (1) revocar los com-ponentes de protección comprometidos en el ataque, retirándolos delrepositorio de componentes de protección y (2) analizar el ataque rea-lizado con el objetivo de identificar las posibles fallas de seguridaddel componente de protección para corregirlas. Al comprometerse laseguridad de un componente de protección, la entidad para la gestiónde protecciones procede a reemplazar dicho componente por uno quebrinde un servicio equivalente.

6.3.6 Entidades finales

Son las fábricas de software que solicitan los servicios de protecciónde software a la SPI.

Las entidades finales disponen de una plataforma de protección,que les permite aplicar los mecanismos de protección a cada uno de


los productos de software desarrollados. Los mecanismos de protec-ción de la entidad final son almacenados en un repositorio local paramecanismos de protección.

Uno de los servicios proveídos por la SPI es precisamente la diver-sificación de software, lo que reduce el impacto de un ataque satis-factorio. El problema principal que impone la diversidad de software,es la actualización particular a cada instancia de software comerciali-zado. Para ello, la SPI provee un sistema para la gestión de softwarediversificados a cada entidad final. Este sistema le permite gestionar,de forma eficaz, la diversificación de cada una de las actualizacionesde las diferentes instancias de los software comercializados.

6.3.7 Soporte

Los componentes de soporte, como su nombre lo indica, brindan fun-cionalidades de soporte a la infraestructura para su correcto funcio-namiento. A continuación se describen los principales componentesde soporte.

Lista de revocación de componentes de protección

Contienen los números de serie de los componentes de protecciónque han sido comprometidos por un ataque. Las entidades finalesdescargan las listas de revocación de componentes de protección des-de la entidad para la gestión de protecciones. Antes de proteger unsoftware, la entidad final verifica que ninguno de los componentespertenecientes a un mecanismo de protección se encuentre en la listade revocación. En caso que algún componente haya sido revocado, laentidad final solicitará la sustitución por componente equivalente.

Sistema de gestión de identificadores únicos de objetos

Tanto las técnicas, algoritmos, componentes, mecanismos y platafor-mas de protección requieren que sean identificados de forma únicaen la SPI. Dicha identificación se hace a partir de los identificadoresúnicos de objeto (Object identifier (OID)), por lo que la SPI dispone unsistema que permita la gestión interna de los mismo.

6.4 procesos 115

Protocolos de comunicación

La comunicación entre entidades finales con la infraestructura, así co-mo como la comunicación entre las distintas entidades de la propiainfraestructura, debe realizarse con la debida seguridad, garantizán-dose la autenticación entre entidades y la privacidad e integridad delos datos transmitidos. Adicionalmente, se debe asegurar el no repu-dio de las transacciones entre la SPI y las entidades finales. Ademásde las listas de revocación de componentes de protección, la SPI brin-da protocolos de verificación en línea para chequear el estado de loscomponentes.

6.4 procesos

Entre los principales procesos que se llevan cabo en la SPI se en-cuentran la solicitud de un mecanismo de protección, el proceso deprotección de un software y la revocación de un componente de pro-tección.

6.4.1 Solicitud

El proceso de solicitud de un mecanismo de protección es iniciadopor parte de una entidad final, a la entidad encargada de la gestiónde los mecanismos de protección.

Para realizar una solicitud, la entidad final debe realizar un levanta-miento de los requisitos de protección durante el proceso de desarro-llo de software, con el objetivo de identificar los servicios de seguri-dad a solicitar. Estos requisitos son expresados a partir de un modelode amenazas del software que se desea proteger.

Los requisitos son enviados a la entidad que gestiona los meca-nismos de protección, la cual se encarga de procesarlos y procede aconfigurar el mecanismo de protección que responde a estos requisi-tos.

Como resultado del proceso, la entidad final obtiene un mecanismode protección acorde a sus necesidades.


6.4.2 Protección

Una vez que la entidad final dispone de un mecanismo de protección,emplea la plataforma de protección para aplicar el mecanismo encuestión al software que desea proteger.

Dicho proceso ocurre de forma automatizada durante el procesode compilación. De esta forma, la entidad final obtiene un softwareprotegido acorde a los requisitos de seguridad previamente identifi-cados.

Una descripción más detallada de la plataforma de protección, asícomo del proceso de protección, puede ser visto en la sección 6.5.1.

6.4.3 Revocación

Si se detectada una violación de un software protegido, la entidad ges-tora de los mecanismo de protección, procede a identificar los com-ponentes comprometidos, lo cual genera una solicitud de revocaciónde dichos componentes.

Como resultado, se retiran los componentes comprometidos delrepositorio y emite una notificación a la entidad encargada del diseñode los algoritmos de protección, con el objetivo de realizar un análisisde la violación.

6.5 implementación de una spi basada en redes avi

En definitiva, una SPI es una infraestructura compleja que requierede numerosos recursos y de la participación de especialistas en di-versos campos de la ingeniería informática para su puesta en marcha.El desarrollo de una SPI completa, está por tanto fuera del alcancedel actual trabajo. En este punto se describe la implementación de unsubconjunto mínimo de servicios, componentes y procesos que con-forman una SPI basada en la propuesta de protección del capítulo4.

En la sección 6.5.1 se describe la estructura y funcionamiento de laplataforma de protección, mientras que en la sección 6.5.2 se describela implementación de un componente de protección basado modeloAVI propuesto.

6.5 implementación de una spi basada en redes avi 117

Esta implementación servirá de base para la experimentación quese llevará a cabo en el capítulo 7.

6.5.1 Desarrollo de la plataforma de protección

De forma general, la plataforma de protección propuesta, está estruc-turada por una capa de compilación y una capa de protección. Lacapa más baja representa el compilador en sí mismo, el cual da sopor-te a los mecanismos de protección ubicados en la capa superior. Lainformación que se intercambia entre ambas capas es la representa-ción intermedia (Intermediate representation (IR)) del código, generadadurante el proceso de compilación (ver figura 24).

Capa de protección

Capa de compilación

IR IR protegida

Figura 24 Plataforma de protección.

El proceso de compilación está constituido por un conjunto de fa-ses, a lo largo de las cuales se realizan diversas transformaciones so-bre el código fuente de la aplicación, resultando un código máquinaque pueda ser ejecutado por un procesador (ver figura 25):

1. Procesamiento inicial (front-end). Realiza un análisis léxico, sin-táctico y semántico del código fuente para finalmente transfor-marlo a una representación intermedia (IR) manejada y trans-formada las restantes fases del proceso de compilación.

2. Procesamiento intermedio (midlle-end): En esta fase se realizantransformaciones de optimización sobre la IR obtenida de lafase anterior.


3. Procesamiento final (back-end). Genera el código máquina a par-tir de la IR previamente optimizada y por último realiza otraoptimización, dependiendo en este caso de la arquitectura delprocesador.

Proceso de Compilación

Procesamiento Intermedio

(midlle-end)

Procesamiento Inicial

(front-end)

IR

<<goal>>

Traducir código fuente en código máquina.

<<physical>>

Compilador

<<people>>

Programador

<<physical>>

Opciones de complicación

Código fuente

Código máquina

<<control>><<achieve>>


IR optimizado

Procesamiento Final

(back-end)

Figura 25 Proceso de compilación.

La propuesta de solución consiste en adicionar una nueva fase alproceso de compilación, la cual manipularía convenientemente el IRpara insertar el mecanismo de protección (ver figura 26).

Proceso de Compilación

<<goal>>

Traducir código fuente en código máquina protegido

<<physical>>

Compilador

<<people>>

Programador

<<physical>>

Opciones de complicación

Código fuente

Código máquina protegido

IR

<<control>><<achieve>>


IR

Procesamiento Final

(back-end)

Procesamiento Intermedio (midlle-end)

ObtimizaciónProtección IR

Procesamiento Inicial

(front-end)

<<physical>>

Opciones de protección

<<supply>>

<<physical>>

Componentes de protección.

<<supply>>

Figura 26 Proceso de compilación aplicando la protección.


Dicha fase se ubicaría al inicio del procesamiento intermedio, dadoque el IR manejado a este nivel es independiente del lenguaje deprogramación y de la arquitectura del procesador.

El proceso de protección tiene como objetivo insertar de forma au-tomatizada un mecanismo de protección en el código del software.Para ello, toma como entrada el IR proveniente del front-end del com-pilador y genera como resultado el IR protegido. De esta forma, elproceso de compilación sigue su curso natural, sin que se requierade una intervención activa del desarrollador durante el proceso deprotección.

En la figura 27 se representa un diagrama con las principales clasesagrupados por paquetes que intervienen en el proceso de protección.



Marco de trabajo de compilación

Compilador Administrador de mecanismos

Administrador de componentes

Cola de mecanismos

Cola de componentes



invoca

crea

crea

crea

crea

invoca

administra

administra

{ordenado}1..*

1

{ordenado}1..*

1

Figura 27 Diagrama de las clases principales de la plataforma de protección.

El paquete Marco de trabajo de compilación representa el compiladorempleado, así como el resto de los componentes que le brindan so-porte. Por otra parte, el paquete Mecanismo de protección y Componentede protección representan el conjunto de clases que administran losmecanismos y componentes de protección respectivamente.

En el paquete Mecanismo de protección, la clase Administrador de me-canismos administra los distintos mecanismos de protección que pue-


den ser empleados. Para ello, crea una Cola de mecanismos con losMecanismos de protección apropiados y ordenados según su uso.

Cuando un Mecanismos de protección es creado, este invoca a su vezal Administrador de componentes de protección, que se encarga de crearigualmente una Cola de componentes con los Componentes de protecciónque son empleados por el Mecanismo de protección.

De forma general, este diseño permite que se incorporen nuevosMecanismos y Componentes de protección a la plataforma, sin que seanecesario modificar su código fuente y volver a compilarla.

Un ejemplo del funcionamiento general de la plataforma puede servisto en el diagrama de secuencia de la figura 28.

Administrador de componentes

Administrador de mecanismos


Cola de componentes

Cola de mecanismos

OfuscaciónCompilador AVI

establecer componente 1

6:

establecer componente 2

7:

solicitar8:

16:

establacermecanismo

2:

solicitar3:

19:

solicitar5:

17:

invocar9:

invocar12:

15:

18:

invocar4:

proteger13:

14:

solicitar1:

proteger10:

11:

Figura 28 Diagrama de secuencia del proceso de protección.

Los Administradores de mecanismos y componentes de protecciónse encargan de establecer sus respectivas colas. En este caso, la plata-forma está compuesta por un solo Mecanismo de protección integrado


por dos Componentes de protección: AVI y Ofuscación. La solicitud deprotección viaja desde el Compilador hasta los Componentes de protec-ción. Una vez que la representación intermedia del código fuente esprotegida, es devuelta al compilador para que continue con el restodel proceso de compilación.

El diseño lógico de la plataforma antes descrito fue implementadomediante el compilador Microsoft Phoenix3. Este compilador, presen-ta una arquitectura extensible mediante componentes (plug-in), quepermiten el acceso al midlle-end del compilador y por tanto, realizartransformaciones sobre la representación intermedia del código fuen-te durante su compilación.

Una vista física de la arquitectura para el ejemplo anterior puedeser vista en la figura 29.


<<component>>

Administrador de mecanismos

<<component>>

Mecanismo 1


<<component>>

Administrador decomponente

<<component>>

Ofuscación

<<component>>

AVI

Marco de trabajo de compilación

<<component>>

Compilador phoenix<<use>>

<<use>><<use>>

Figura 29 Diagrama de componentes de la plataforma de protección.

6.5.2 Desarrollo del componente de protección basado en AVI

El Componente de Protección basado en la propuesta de red de auto-verificación no determinista, implementa el algoritmo 3 descrito en lasección 4.2.4.

El proceso de protección llevado a cabo por este componente, comoparte del proceso de compilación, puede ser visto en la figura 30.

3 http://research.microsoft.com/en-us/collaboration/focus/cs/phoenix.aspx

http://research.microsoft.com/en-us/collaboration/focus/cs/phoenix.aspx


Protección

IR protegido

<<physical>>

Opciones de protección

<<supply>>

<<physical>>

Componentes de protección

<<supply>>

<<physical>>

Componentes de compilación

<<supply>>

<<people>>

Programador

<<control>>

<<goal>>

Insertar mecanismo protección

<<achieve>>

Conjunto de

Nodos

Inserción

IR IR

Configuración

IR

IR

<<supply>>

Configurar grafo de verificación

Configurar grafo de respuesta

Insertar conjunto de verificación

Insertar conjunto de respuesta

Replicación de nodos

Figura 30 Proceso de protección.

En el proceso intervienen un conjunto de recursos necesarios comoson los nodos de verificación y de respuesta. Además se especifica unconjunto de opciones de protección tales como la cantidad de nodos,las probabilidades de detección y respuesta, etc.

Una vez que la red de auto-verificación ha sido insertada y se haconcluido el proceso de compilación, se procede a actualizar el con-junto de las firmas de integridad.

A continuación se describen algunos elementos del diseño de losnodos de verificación y respuesta tenidos en cuenta en la implemen-tación de la propuesta.

Nodo de verificación

El nodo de verificación es implementado siguiendo el algoritmo deverificación de integridad 1 propuesto en el capítulo 4. Dicho algorit-mo presenta dos elementos esenciales a tener en cuenta en su diseño:(1) la generación de números pseudo aleatorios para lograr el com-portamiento no determinista y (2) la función resumen para calcularla firma de integridad.


Es necesario destacar algunos elementos de seguridad a tener encuenta en la implementación de los nodos de verificación, atendiendoa los elementos antes señalados:

1. Desde los nodos de verificación, es conveniente no realizar lla-madas a funciones generadoras de números pseudo aleatorioso funciones resúmenes implementadas en el sistema operativoo bibliotecas de terceros. Es poco frecuente que un software ha-ga uso de este tipo de funciones, a menos que sea de propósitoespecífico, por ejemplo, de uso criptográfico. La llamada a estetipo de funciones revela la posición del nodo de verificación enel software con relativa facilidad. Para el atacante es muy sen-cillo colocar un punto de ruptura en bibliotecas externas queexportan dicha funcionalidad y localizar el origen de la llamadaque se corresponde con un nodo de verificación en el software.

2. Evitar el uso de una función global a nivel de software, parala generación de números pseudo aleatorios y cálculo de valorresumen, que sean llamadas desde cada nodo. Si el atacantelocaliza dichas funciones, le resulta muy fácil localizar los nodosde verificación a partir del grafo de llamadas (call graph).

3. Evitar la implementación de funciones de generación de núme-ros pseudo-aleatorio y el cálculo de valor resumen fuera de cadanodo de verificación. Dichas funcionalidades deben estar diver-sificadas de un nodo a otro, ya sean estructural o funcionalmen-te para evitar un ataque por comparación que permita, a partirde un nodo, localizar el resto.

De forma general, cada nodo de verificación debe disponer de supropio mecanismo de generación de números pseudo aleatorios ycálculo de valores resúmenes, ambos debidamente diversificados deun nodo a otro.

Para del cálculo del valor resumen, se emplea una función resumende un solo sentido (one-way hash function). Se emplea este tipo defunción por las siguientes propiedades:

1. Capacidad de compresión: Una función resumen recibe comoentrada un conjunto de información de tamaño arbitrario, dan-


do siempre como resultado un valor de tamaño constante (co-nocido como valor resumen), significativamente menor al de losdatos de entrada.

2. Facilidad de cálculo. Es fácil calcular el valor resumen a partirde los datos de entrada.

3. Colisión simple: Desde el punto de vista de cómputo, debe serimpracticable, conocido el valor de los datos de entrada, encon-trar otro conjunto de datos a partir del cual se obtenga el mismovalor resumen.

Las dos primeras propiedades permiten minimizar el impacto enel rendimiento y el tamaño que supone el mecanismo de protecciónpara la aplicación.

Según la tercera propiedad, al atacante le resultaría difícil encontrarun fragmento de código, cuyo comportamiento respondiese a sus ne-cesidades y además diera como resultado el mismo valor resumen delfragmento de código original. Por este motivo, el ataque va dirigido amanipular las comparaciones de las firmas de integridad, en lugar dellevar a cabo un análisis criptográfico de la función resumen. Para laimplementación de la función encargada de calcular el identificadorde un nodo, se diseñaron funciones resúmenes más ligeras basadasen la combinación de algunas operaciones aritméticas y lógicas.

Nodo respuesta

Las especificaciones del diseño e implementación de la respuesta va-ría en dependencia del tipo de respuesta (ver sección 3.3.2).

En la presente propuesta, las respuestas consisten en una notifica-ción local ante la detección de una manipulación. El objetivo de estapropuesta es comprobar la eficacia del mecanismo de protección anteataques, por lo que es suficiente una respuesta de este tipo.

Dado que los nodos respuesta también tienen un comportamientono determinista, es necesario tener en cuenta las mismas restriccionessobre el generador de números pseudo aleatorios expuesto anterior-mente.

6.6 conclusiones 125

6.6 conclusiones

En el presente capítulo se abordó el diseño de una Infraestructurapara la Protección de Software.

Al respecto, se definieron los requisitos que debe seguir la infraes-tructura, identificando como requisito esencial la automatización delproceso de protección.

La infraestructura fue descrita a partir de los servicios, componen-tes y procesos que la conforman. Los servicios brindados están rela-cionados con los atributos de seguridad que se desean garantizar enun software. Entre los componentes de la infraestructura, se desta-can como esenciales la Plataforma de protección que hace uso de losMecanismos de protección para garantizar los servicios antes mencio-nados durante el proceso de protección.

Como resultado del diseño realizado, se obtuvo una Plataformade protección extensible que puede soportar diversos mecanismosde protección. Concretamente se llevo a cabo la implementación dedicha plataforma, unida a la implementación del mecanismo de auto-verificación de integridad no determinista.

7E VA L U A C I Ó N E X P E R I M E N TA L

En este capítulo se exponen los resultados experimentales de la eva-luación de la propuesta de red de auto-verificación de integridad.

En primer lugar se realiza un conjunto de experimentos para esti-mar la mejor configuración de la propuesta desde el punto de vistade seguridad y rendimiento.

Por un lado se evalúa la seguridad de varias implementacionesconcretas de la propuesta, utilizando para ello el modelo expuesto enel capítulo 5. Los resultados representan estimaciones cuantitativas,tanto del esfuerzo necesario para realizar un ataque exitoso, comodel nivel de fuga de información del mecanismo de protección.

Por otro lado se evalúa el impacto que produce el despliegue delmecanismo de protección sobre un software determinado. Este im-pacto se expresa en términos de aumento en el tamaño del código yen tiempo de ejecución.

Como software de prueba para los experimentos, se utilizó la sui-te SPECint2000 del banco de prueba SPEC CPU2000 (Henning, 2000).Específicamente, se seleccionó el software de compresión de datos164.gzip de tamaño pequeño (7.6 KLOC). Esta aplicación representaun caso típico de componente software con el que se construyen apli-caciones complejas, y donde las tareas de proceso de datos y controlestán bien balanceadas. Incluye una amplia cantidad de métodos y ca-sos de uso que cubren una gran variedad de configuraciones del GCF.Estas circunstancias permiten generalizar los resultados obtenidos enlos experimentos así como extrapolar las conclusiones a aplicacionesmás complejas.

Todos los experimentos se ejecutaron en un procesador Intel Corei7 920 de 64 bits, con 4 núcleos a 2.66 GHz. El procesador dispone de

127

128 evaluación experimental

una caché L1 de datos y código de 32 KB respectivamente, una cachéL2 unificada por cada núcleo de 256 KB y una caché L3 unificada de8 MB para todos los núcleos.

7.1 configuración del mecanismo de protección

En el capítulo 5 se pudo apreciar que la probabilidad de emitirseuna respuesta, tras una modificación del software protegido, influyetanto en la cantidad de información que se filtra del mecanismo deprotección (epígrafe 5.2.1), como en la estimación del umbral en losalgoritmos de localización y comprobación (epígrafe 5.2.3).

Mientras menor sea el valor de la probabilidad de emitirse una res-puesta, menor será la fuga de información sensible del mecanismode protección y mayor será el umbral a fijar por el atacante. De es-ta forma, se requiere identificar la configuración más apropiada delmecanismo de protección para alcanzar los valores de probabilidaddeseados, a la vez que no se imponga un impacto apreciable en ladisponibilidad del software protegido. La configuración deseable esaquella en la cual se maximice la seguridad (condicionada fundamen-talmente por la probabilidad de emitirse una respuesta) y se minimiceel impacto en la disponibilidad del software protegido.

Para cada aplicación debe ser el usuario del SPI el que determinecuál es la mejor solución de compromiso entre estas dos variables. Sinembargo, obtener la configuración de la red que garantice este com-promiso no es una tarea inmediata. En este primer grupo de experi-mentos se pretende profundizar en el entendimiento de la dinámicadel modelo de red AVI no determinista, con el fin de:

• Identificar los factores primordiales que influyen en la seguri-dad y disponibilidad, así como sus interacciones.

• Estimar los niveles (valores) de cada factor necesarios para lo-grar la configuración deseada

Con este fin, la estrategia experimental básica a seguir es la de va-riar un factor, mientras que el resto se mantienen fijos (Czitrom, 1999).No obstante, este procedimiento no permite estimar las interaccionesentre factores, por lo que se propone utilizar la estrategia de experi-

7.1 configuración del mecanismo de protección 129

mento factorial (Design of Experiments (DOE)) propuesta en (Antony,2003; Montgomery, 2009).

Inicialmente se llevará a cabo una planificación del experimento.Posteriormente se realizará un escrutinio de los factores e interaccio-nes influyentes. Por último se realizará una evaluación cuantitativade los efectos principales para configurar el mecanismo.

7.1.1 Planificación del experimento

Los puntos claves de las directrices propuestas por el DOE son:

1. Selección de la variable de salida.

2. Selección de los factores y sus niveles.

3. Selección del diseño experimental.

4. Ejecución del experimento.

A continuación se detallan cada uno de estos elementos.

Selección de la variable de salida

Con la realización del experimento se pretende llevar a cabo una ca-racterización del proceso, que en este caso es el comportamiento delmecanismo de protección ante una manipulación del software prote-gido. Específicamente, se pretende realizar un escrutinio (screening1)de los factores que influyen en las siguientes variables de salida:

• Probabilidad global de Respuesta (PR): Probabilidad global de res-puesta ante una manipulación de un nodo de la red de auto-verificación.

• Sobrecarga de Tiempo (ST): Sobrecarga de tiempo de ejecución delsoftware debido al mecanismo de protección.

1 Para más detalle sobre los diseños de escrutinio o tamizado en el contexto del DOE,refiérase a (Antony, 2003, capítulo 5).


Selección de los factores y sus niveles

Una vez determinadas las variables de salidas del proceso, es nece-sario identificar los factores e interacciones potenciales que puedantener efecto sobre las mismas. Dichos factores podrán ser controla-bles o no controlables2.

Los factores controlables que se han identificado en el experimentoson:

pc : Probabilidad de verificación pc de los nodos de verificación.

pr : Probabilidad de respuesta pr de los nodos de respuesta.

c : Cardinalidad del conjunto de verificación |C |.

r : Cardinalidad del conjunto de respuesta |R |.

h : Número máximo de verificaciones que puede recibir cada nododurante una ejecución del software (se corresponde con el um-bral del algoritmo 1 de la sección 4.2.1).

Adicionalmente, existen otros factores de ruido, no controlables,que influyen en la variable de salida PR. Estos factores dependen fun-damentalmente del caso de prueba con el cual se ejecute el software,específicamente con la cobertura de código que cada caso de pruebaproduzca, esto es:

1. Proporción de nodos de verificación ejecutados del total de no-dos de verificación.

2. Proporción de nodos de respuesta ejecutados del total de nodosde respuesta.

3. Proporción de nodos de respuesta ejecutados después del nodoque lleva a cabo la verificación, respecto del total de nodos derespuesta ejecutados.

4. Número de ejecuciones de los nodos de verificación.

2 Los factores no controlables o factores de ruido, son aquellos que influyen en lavariable de salida del proceso y cuyos valores no pueden ser fijados a convenienciapara la configuración del sistema.


Debido a estos factores de ruido, resulta muy difícil determinarun modelo matemático que caracterice el sistema y que permita suposterior optimización. Esto significa que el modelo generado seríadependiente del caso de prueba y del software protegido. Por estemotivo, la intención del experimento es identificar la mejor configu-ración de los factores controlables que sean influyentes, de forma quese minimice el efecto de los factores de ruido sobre las variables desalida del proceso.

Como se establece en (Montgomery, 2009), para determinar los fac-tores e interacciones influyentes, es suficiente seleccionar dos nivelespor factor. Los niveles seleccionados para cada uno de los factorescontrolables pueden ser vistos en la tabla 3:

Nombre Nivel inferior Nivel superior

pc 0.2 0.8

pr 0.2 0.8

C 100 300

R 500 1500

H 20 200

Tabla 3 Niveles por factor.

Selección del diseño experimental

Para el experimento, se aplicó un diseño factorial completo 2k aleato-rizado y se realizaron dos réplicas. Una réplica implica repetir más deuna vez el experimento bajo una misma configuración. Esto permiteobtener una estimación del error experimental (por ejemplo, al reali-zar la medición de la variable de salida) y en consecuencia obtenermás precisión sobre el efecto estimado de los factores e interacciones.

Tras realizar un análisis de los factores controlables, se tomó ladecisión de tener en cuenta sólo las interacciones de orden dos.

Ejecución del experimento

Durante el experimento, se generaron 32 instancias de software deprueba con distintas configuraciones del mecanismo de protección


acorde a los niveles fijados en la tabla 3. La inserción del mecanismode protección en el software de prueba, fue llevado a cabo medianteel algoritmo de integración 3 propuesto en el capítulo 4.

Teniendo en cuenta los factores de ruido comentados anteriormen-te, existen tres categorías significativas de nodos de verificación quevale la pena analizar en el experimento:

• Nodos tipo 1 o iniciales: un nodo es inicial cuando existen muypocos o ningún nodo de respuesta anteriores a él y además seejecuta sólo una vez.

• Nodos tipo 2 o finales: un nodo es final cuando existen muypocos o ningún nodo respuesta posteriores a él, y se ejecutasólo una vez.

• Nodos tipo 3 o intermedios: un nodo se dice que es intermediocuando existen varios nodos de respuesta antes y después de él,y se ejecuta más de una vez.

Del total de nodos de verificación insertados, se seleccionó unamuestra de tres nodos en cada instancia acorde a la anterior clasi-ficación. De igual forma, se seleccionó el caso de prueba que garanti-zara la ejecución de los tres nodos y el mayor grado de cobertura decódigo posible.

El proceso de experimentación fue el siguiente. Para evaluar la va-riable de respuesta PR, se modificó un nodo del GCF y se ejecutó lainstancia de software un número de veces suficiente para estimar laprobabilidad con una certidumbre del 95 %. Dicho proceso se repitiópara los otros dos nodos. Como resultado, se realizaron 192 experi-mentos, los cuales pueden ser vistos en la tabla C.

Para la variable de respuesta ST, se procedió a modificar un nodode verificación y se ejecutó cada instancia de software con el caso deprueba que proporcionaba la mayor cobertura de código. Esto garanti-za que se activen la mayor cantidad de nodos de verificación posibles.Para cada instancia se calculó el tiempo de ejecución para un totalde 64 experimentos. Los resultados obtenidos pueden ser visto en latabla C.


Los datos resultantes del experimento fueron analizados emplean-do el software estadístico Minitab3 con un nivel de significancia α =0.01

4.

7.1.2 Escrutinio de los factores

A continuación se describe el análisis de los resultados obtenidos du-rante el experimento (tabla C), para determinar los factores e interac-ciones influyentes para las variables de salida PR y ST.

Variable de salida PR

La figura 31 representa la gráfica de probabilidad normal de efectos es-tandarizados (Antony, 2003, epígrafe 4.4.5) de la variable de respuesta,para cada uno de los nodos analizados. Los efectos de los factores einteracciones principales se representan contra la probabilidad cumu-lativa (expresada en tanto por ciento).

Los efectos de factores e interacciones no influyentes (puntos ne-gros), tienden a estar alineados de forma recta aproximadamente.Los efectos de factores e interacciones influyentes (puntos blancosetiquetados) se encuentran alejados de dicha alineación. La línea deregresión sirve de referencia gráfica para establecer la diferencia entrefactores influyentes y no influyentes.

Para corroborar los resultados obtenidos a partir de la gráfica nor-mal, se emplea una gráfica de Pareto de efectos estandarizados (An-tony, 2003, epígrafe 4.4.4). En esta gráfica (ver figura 32) se muestrael valor absoluto de los efectos de los factores e interacciones y se tra-za una linea recta de referencia cuyo valor es calculado utilizando elmétodo de Lenth (Lenth, 1989). Cualquier efecto que se extiende másallá de esta línea es potencialmente importante. Puede apreciarse quelos resultados coinciden en ambas gráficas.

3 www.minitab.com4 Utilizado en pruebas de hipótesis, alfa (α) es el máximo nivel de riesgo aceptable

para rechazar una hipótesis nula verdadera (error de tipo I) y se expresa como unaprobabilidad cuyos valores se encuentran entre 0 y 1. Alfa con frecuencia es denomi-nado nivel de significancia.

http://www.minitab.com/


1007550250

99

95

90

80

70

60

50

40

30

20

10

5

1

Efecto estandarizado

Por

cen

taje

No significativoSignificativo

Tipo de efecto

pr-R

pc-R

pc-pr

R

pr

pc

(a) Nodo 1.

1050-5-10

99

95

90

80

70

60

50

40

30

20

10

5

1


Por

cen

taje


Tipo de efecto

pr-R

pc-R

pc-pr

R

pr

pc

(b) Nodo 2.

100500-50-100

99

95

90

80

70

60

50

40

30

20

10

5

1


Por

cen

taje


Tipo de efecto

R-H

C-H

C-R

pr-H

pr-R

H

R

C

pr

(c) Nodo 3.

Figura 31 Gráfica normal de efectos estandarizados para PR.


H

pr-H

C-H

pr-C

R-E

pc-H

C

pc-C

C-R

pc-R

pr-R

R

pc-pr

pc

pr

100806040200

Térm

ino


3,5

(a) Nodo 1.

C-H

H

pr-C

pr-H

pc-C

R-H

pc-H

C

C-R

pr-R

pc-R

pc-pr

R

pc

pr

1086420

Térm

ino


3,51

(b) Nodo 2.

pc-H

pc-R

pc

pc-C

pc-pr

pr-C

C-R

C-H

C

pr-R

R-H

R

pr-H

pr

H

100806040200

Térm

ino


3,5

(c) Nodo 3.

Figura 32 Gráfica de Pareto de efectos estandarizados para PR.


La tabla 4 resume los factores y las interacciones (de orden 2) quetienen un efecto significativo sobre la variable de salida PR para lostres nodos analizados. El resto de los factores e interacciones puedenser tratados como factores inactivos.

Factores e interacciones significativos

Nodo 1 pc, pr, R, pc-pr, pc-R, pr-R

Nodo 2 pc, pr, R, pc-pr, pc-R, pr-R

Nodo 3 pr, C, R, H, pr-R, pr-H, C-H, C-R, R-H

Tabla 4 Factores e interacciones significativos.

A partir de las gráficas expuestas en las figuras 31 y 32 se pue-den obtener las siguientes conclusiones para cada uno de los nodosanalizados:

1. Nodo 1.

a) Los factores pc, pr y la interacción entre ambos son los másinfluyentes.

b) El factor R tiene una influencia significativa, pero en menorgrado que pc, pr.

c) Los factores C y H no tienen influencia significativa.

2. Nodo 2.

a) Los factores pc, pr y R son los más influyentes. Se repitenlos factores pc y pr respecto al nodo 1, pero el factor Ren este caso, tiene mayor influencia que las interaccionesentre estos factores. Esto se debe fundamentalmente a laposición del nodo 2 en el GCF. Al estar situado al finaldel GCF, la cantidad de nodos respuestas que se activandespués de este nodo es mucho menor respecto al nodo 1.

b) Las interacciones pc-pr, pc-R y pr-R tienen una influenciasignificativa, pero en menor grado.

c) Los factores C y H no tienen influencia significativa.

3. Nodo 3.


a) Los factores H, pr y la interacción entre ambos, son los másinfluyentes. Generalmente este tipo de nodo se encuentraen el cuerpo de un bucle, lo que constituye un factor de rui-do. Por este motivo, tiene mayor probabilidad de realizarverificaciones que el resto de los nodos.

b) Los factores R, C y las interacciones R-H, pr-R, C-H y C-Rtienen una influencia significativa, pero en menor grado.

c) El factor pc en este caso, no tienen influencia sobre la va-riable de salida.

Variable de salida ST

La figura 33 muestra las gráficas de efectos estandarizados para lavariable de salida ST.

50403020100-10-20

99

95

90

80

70

60

50

40

30

20

10

5

1


Por

cen

taje


Tipo de efectoC-R

R

C

(a) Normal.

pc-R

R-H

pr-H

pr

pc-H

pc-C

pr-R

pc

pc-pr

pr-C

H

C-H

C-R

C

R

50403020100

Térm

ino


3,51

(b) Pareto.

Figura 33 Gráfica de efectos estandarizados para ST.


La figura 33a representa la gráfica normal de efectos estandariza-dos. Para corroborar los resultados obtenidos, se muestra la gráficade Pareto de efectos estandarizados 33b. En ambos gráficas se puedeapreciar que los factores C, R y la interacción entre ambos tienen unefecto significativo sobre la variable de salida. El resto de los factorese interacciones pueden ser tratados como inactivos.

7.1.3 Cuantificación de los efectos principales

Una vez determinado los factores significativos, se realizó un estudioparticular sobre los mismos con el objetivo de evaluar el grado delefecto de cada factor sobre las variables de salida PR y ST.

Adicionalmente, se realizó un estudio del efecto de las interaccio-nes influyentes para identificar una adecuada configuración del me-canismo.

Variable de salida PR

Para el Nodo 1 (ver figura 34), los factores pr y pc tienen un efectoprincipal5 absoluto más grande respecto al factor R.

0,80,2

0,10

0,08

0,06

0,04

0,020,80,2

1500500

0,10

0,08

0,06

0,04

0,02

pc

Med

ia

pr

R

Figura 34 Gráfica de efectos principales para el Nodo 1.

5 El efecto principal (main effect) es la diferencia entre las medias de los niveles de unfactor. Esto es Ef = F(+1) − F(−1), donde F(+1) y F(−1) son las respuestas promediode un factor para los niveles alto y bajo respectivamente. Para más detalles refiérasea (Antony, 2003, epígrafe 4.1.1).


Un incremento significativo de R en 1000 nodos al cambiar del ni-vel bajo al alto, tiene poco impacto en el decremento del valor de lavariable de salida.

Acorde a los resultados mostrados en la tabla 4, las interaccionesanalizadas para este nodo fueron pc-pr, pc-R y pr-R (ver figura 35).

0,80,2

0,20

0,15

0,10

0,05

0,00pr

Med

ia

0,20,8

pc

1500500

0,12

0,09

0,06

0,03

R

Med

ia

0,20,8

pc

1500500

0,12

0,09

0,06

0,03

R

Med

ia

0,20,8

pr

Figura 35 Gráfica de interacción entre factores para PR del Nodo 1.

Para obtener el valor más bajo de la variable de salida PR, los re-sultados indican que:

1. Interacción pc-pr. Tanto pc como pr deben ser fijados a su nivelbajo de 0.2.

2. Interacción pc-R. El factor R debe ser fijado a su nivel alto de1500 nodos, mientras que pc es fijado a su nivel bajo de 0.2.

3. Interacción pr-R. El nivel del factor R debe ser fijado a su nivelalto de 1500 nodos y pr a su nivel bajo de 0.2.

Como resultado del análisis de las interacciones para este nodo, losfactores pc y pr deber ser colocados en su nivel bajo, mientras que elfactor R se fija en su nivel alto. Esta configuración no contradice los


resultados obtenidos en la gráfica de los efectos principales (figura34).

Una vista general de la configuración de los factores para este nodopuede ser corroborada en la gráfica de cubos de la figura 36.

1500

500

0,8

0,20,80,2

R

pr

pc

0,16190

0,039840,00997

0,03968

0,19133

0,047030,01170

0,04813

Figura 36 Gráfica de cubos para el Nodo 1.

En el caso del Nodo 2 (ver figura 37), el efecto principal absolutode los tres factores es equivalente.

0,80,2

0,0010

0,0008

0,0006

0,0004

0,00020,80,2

1500500

0,0010

0,0008

0,0006

0,0004

0,0002

pc

Med

ia

pr

R



El factor R tiene un efecto mayor en este caso respecto al Nodo 1,debido a que el nodo se encuentra en una posición del GCF en la queexisten muy pocos nodos respuestas posteriores a él.

Se analizaron las mismas interacciones entre factores que en el No-do 1 (ver figura 38). La configuración de los factores para obtener elvalor más bajo de la variable de salida PR es la misma que en el nodoanterior.

0,80,2

0,0016

0,0012

0,0008

0,0004

0,0000pr

Med

ia

0,20,8

pc

1500500

0,0016

0,0012

0,0008

0,0004

0,0000R

Med

ia

0,20,8

pc

1500500

0,0016

0,0012

0,0008

0,0004

0,0000R

Med

ia

0,20,8

pr


Es necesario destacar que la interacción pc-R y pr-R en este casoes más fuerte, lo cual es consecuente con el efecto del factor R (vergráfica de efectos principales del Nodo 2, figura 37).

La configuración general de los factores de este nodo puede servista en la gráfica de cubos de la figura 39.


1500

500

0,8

0,20,80,2

R

pr

pc

0,00074

0,000230,00006

0,00024

0,00265

0,000600,00016

0,00059


Para el Nodo 3 (ver figura 40), los efectos principales absolutos másgrandes se corresponden con pr y H. Esto se debe fundamentalmentea que dicho nodo se ejecuta de forma reiterada por estar en un bucledel GCF. Los factores C y R tienen un efecto principal absoluto máspequeño.

0,80,2

1,0

0,9

0,8

0,7300100

1500500

1,0

0,9

0,8

0,720020

pr

Med

ia

C

R H


Acorde a los resultados mostrados en la tabla 4, las interaccionesanalizadas para este nodo fueron pr-R, pr-H, C-H, C-R y R-H (verfigura 41).


1500500

1,0

0,9

0,8

0,7

R

Med

ia

0,20,8

pr

20020

1,00

0,75

0,50

H

0,20,8

pr

1500500

0,88

0,87

0,86

0,85

0,84

R

100300

C

20020

1,0

0,9

0,8

0,7H

Med

ia

100300

C

20020

1,0

0,9

0,8

0,7

H

5001500

R


Acorde a cada interacción, la configuración adecuada para obtenerel valor más bajo de la variable de salida PR es:

1. Interacción pr-R. El factor pr debe ser fijado a su nivel bajo,mientras que R se fija a su nivel alto.

2. Interacción pr-H. Esta interacción es muy fuerte. Para el nivelbajo de H, el efecto sobre PR es apreciable cuando se pasa del ni-vel bajo de pr a su nivel alto. La mejor configuración se obtienepara H y pr en su nivel bajo.

3. Interacción C-H. Esta interacción es débil. No obstante, la confi-guración adecuada se obtiene para C en su nivel alto y H en sunivel bajo.

4. Interacción C-R. La configuración más adecuada se logra fijandotanto C como R a su nivel alto.

5. Interacción R-H. El nivel del factor R debe ser fijado a su nivelalto, mientras que H se fija a su nivel.


Para este nodo, los factores pr y H deben ser fijados a su nivel bajo,mientras que C y R deben fijarse a su nivel alto, independientementede la interacción que se trate. Estos resultados no contradicen losobtenidos al analizar la gráfica de efectos principales (figura 40).

El gráfica de cubo de la figura 42 permite apreciar de forma clarala configuración de los niveles de cada factor determinante de estenodo para minimizar el valor de la variable de salida PR.

20020

1500

500

300

100

0,80,2

H

R

C

pr

1,00000

0,999920,99835

0,99550

0,99940

0,999400,99917

0,99965

0,90438

0,940700,49020

0,43330

0,97420

0,973130,56975

0,56583


En la tabla 5 se resume el nivel al cuál debe ser fijado cada factor,según el tipo de nodo, para obtener el mínimo valor de PR.

NodoFactor

PRpc pr C R H

Nodo 1 b b i a i 0.099

Nodo 2 b b i a i 0.00006

Nodo 3 i b a a b 0.43

a: alto, b: bajo, i: indiferente

Tabla 5 Niveles de cada factor para minimizar PR.


La columna PR indica el menor valor medio alcanzado para la va-riable de salida a partir de la configuración indicada de los niveles.Puede apreciarse como los factores de ruido hacen que el valor de PRsea distinto de un nodo a otro. El hecho que un nodo se encuentreen un bucle, hace que la probabilidad de respuesta sea alta respectoa los que no lo están. Por otra parte, la probabilidad de respuesta sehace muy pequeña cuando el nodo se encuentra al final del GCF conpocos nodos respuesta que se activen tras él.

De forma general, independientemente del tipo de nodo, los facto-res pc, pr y H deben ser fijados a su nivel bajo, mientras que C y R asu nivel alto.

Variable de salida ST

En la figura 43 se muestra la gráfica de los efectos principales con elobjetivo de evaluar el grado del efecto de los factores C y R sobre lavariable de salida ST.

300100

14,0

13,5

13,0

12,5

12,0

11,5

11,0

1500500

C

Med

ia

R

Figura 43 Gráfica de efectos principales para ST.

Se puede apreciar el decremento del tiempo de ejecución cuandolos factores son fijados a su nivel bajo. El factor R tiene un efecto prin-cipal ligeramente superior al factor C, debido fundamentalmente almayor número de nodos respuesta respecto a los nodos de verifica-ción.

El grado de la interacción C-R sobre la variable de salida ST puedeser vista en la figura 44. Se puede apreciar que el menor tiempo deejecución se logra para los niveles bajos de cada factor, lo cual está encorrespondencia con la gráfica de efectos principales.


1500500

15

14

13

12

11

10

9

RM

edia

100300

C

Figura 44 Gráfica de interacción entre factores para ST.

La configuración para obtener un valor bajo de la variable de sa-lida ST, entra en contradicción respecto a la configuración obtenidapara la variable PR. Esto se debe a que un incremento en el nivel deseguridad, trae asociado un decremento del rendimiento.

A partir de los resultados obtenidos al analizar las variables desalida PR y ST, se proponen distintas configuraciones del mecanismode protección para llevar a cabo el resto de los experimentos (ver tabla6).

Configuraciones

Factor C1 C2 C3 C4 C5

C 64 128 256 512 1024

R 128 256 512 1024 2048

H 1

PR 0.01, 0.001, 0.0001 y 1

Tabla 6 Configuración del mecanismo de protección.

El umbral de verificación para todas las configuraciones es uno,pues es el valor mínimo permisible. En lugar de especificar directa-mente las probabilidades de verificación pc y respuesta pr, se especi-fica la probabilidad global de respuesta PR ante una manipulación. Elvalor de probabilidad igual a uno indica que el comportamiento delmecanismo es determinista. Los nodos respuesta en este caso emitenuna respuesta trivial (solo se almacena en un fichero la notificación

7.2 evaluación del nivel de ofuscación 147

de respuesta), dado que el objetivo del experimento es analizar elcomportamiento del mecanismo de protección.

7.2 evaluación del nivel de ofuscación

Un objetivo a lograr con el comportamiento no-determinista es mini-mizar la fuga de información del mecanismo de protección y con elloaumentar su nivel de ofuscación. Sin embargo, dadas distintas con-figuraciones de una red AVI no es posible conocer, a priori, cuál deellas presenta una mayor ofuscación. El usuario de este tipo de pro-tecciones necesita disponer de alguna métrica que le permita explorardistintas configuraciones en la búsqueda de la solución de compro-miso que mejor se acomode a su aplicación. En este experimento sepretende demostrar la utilidad de la métrica propuesta en el capítulo5 (ver epígrafe 5.2) para evaluar y comparar el nivel de ofuscaciónalcanzado por distintas configuraciones.

Durante el experimento, para cada configuración se calculó la can-tidad de información que se fuga del mecanismo de protección (verecuación 22 de la página 97). Se asumió que la probabilidad de éxitodel ataque es p(e) = 0.5 dado que la mayor fuga de información (peorcaso), ocurre para una incertidumbre equiprobable. En la tabla 7 semuestra los resultados obtenidos.

Configuraciones

PR C1 C2 C3 C4 C5

1 64 128 256 512 1024

0.01 0.32 0.64 1.285 2.57 5.14

0.001 0.032 0.064 0.128 0.256 0.512

0.0001 0.0032 0.0064 0.0128 0.0256 0.0512

Tabla 7 Fuga de información (bits).

Se puede apreciar que a medida que disminuye la probabilidad derespuesta, disminuye la cantidad de información que recibe el ata-cante para cada configuración de forma independiente. El compor-tamiento no determinista disminuye considerablemente la fuga de


información, teniéndose como referencia la máxima fuga de informa-ción en el caso determinista.

La fuga de información por nodo es constante par un valor de PRe independiente del número de nodos de verificación y respuesta.Esto es, fijados los parámetros de la cantidad de nodos, se ajusta PR(mediante los factores pc, pr y H) para que la fuga de informaciónsea la menor.

7.3 evaluación de la disponibilidad

Al aplicar el mecanismo de protección sobre una aplicación, se incu-rre necesariamente en una penalización, tanto en el tiempo de eje-cución, como en el tamaño del software. Esto implica que a mayorgrado de seguridad, se obtendrá una mayor sobrecarga del tamañodel código y del tiempo de ejecución.

En las siguientes secciones se realiza la estimación de la sobrecargadel mecanismo de protección propuesto, respecto a uno equivalentecon un comportamiento determinista.

7.3.1 Sobrecarga del tamaño del código

La sobrecarga del mecanismo de protección se debe al total de no-dos de verificación y de respuestas insertados en el software. Dichasobrecarga se define como S1/S0 , donde S0 y S1 es el tamaño delsoftware protegido con el mecanismo no determinista y deterministarespectivamente.

Tomando como referencia las diferentes configuraciones plantea-das anteriormente (ver tabla 6), se procedió a calcular la sobrecargaen el tamaño que impone el mecanismo de protección para cada con-figuración. Los resultados pueden ser vistos en la figura 45.

La sobrecarga se hace mayor a medida que aumenta el número denodos de verificación y de respuesta. En el peor caso (configuración5), el tamaño de la aplicación es 3 veces mayor.

El aumento respecto al caso determinista, se debe fundamentalmen-te a la lógica asociada a la generación de números pseudo aleatorios,la cual es empleada para lograr el comportamiento no determinista.

7.3 evaluación de la disponibilidad 149

3,1

3,5

3

2,452,5

1,752

mpacto

1,251,41,5Im

1

0,5

0

C1 C2 C3 C4 C5

Configuraciones

Figura 45 Sobrecarga del tamaño impuesto por el mecanismo de protección.

Es necesario destacar que los resultados del experimento puedenparecer engañosamente altos, debido a que el software utilizado parala prueba tiene un tamaño relativamente bajo. Las distintas configura-ciones desplegadas sobre un software de tamaño medio/alto produceun menor impacto. En la figura 46 se muestra el impacto de las apli-caciones incluidas en el benchmark SPEC CPU2000 (Henning, 2000).

0

1

2

3

4

5

6

7

8

9

Impa

cto

Aplicaciones (c, c++)

C1

C5

C4

C3

C2

Figura 46 Sobrecarga del tamaño para distintas aplicaciones.


Las aplicaciones han sido ordenadas en orden creciente de tama-ño. Puede apreciarse que para una misma configuración, y por tantopara un mismo nivel de seguridad, el impacto se hace mucho menora medida que las aplicaciones crecen en complejidad. Por ejemplo,en el caso de la aplicación 176.gcc (193 KLOC) el impacto para laconfiguración más segura (C5) es de apenas 1.37.

Otro aspecto a destacar es la variabilidad (varianza) del impactoal pasar de una configuración a otra para una misma aplicación (verfigura 47).

177.m

esa

255.v

ortex

254.g

ap

252.e

on

300.t

wolf

186.c

rafty

188.a

mmp

175.v

pr

197.p

arser

164.g

zip

256.b

zip2

183.e

quake

179.a

rt

181.m

cf

9

8

7

6

5

4

3

2

1

0

Impacto

Figura 47 Diagrama de cajas de las configuraciones para cada aplicación.

Para aplicaciones de tamaño alto, la variabilidad en el impacto esmucho menor al aumentar el tamaño de la red, respecto a una aplica-ción de tamaño pequeño. Esto implica que, para aplicaciones relativa-mente complejas, la seguridad puede ser aumentada sustancialmenteal aumentar el número de nodos sin que ocurra un impacto signifi-cativo. Por ejemplo, para la aplicación 176.gcc, al pasar de la confi-guración C1 a la C5 se incurre en una penalización de 0.33, frente aun valor de 6.38 para igual cambio de configuración en la aplicación181.mcf de menor tamaño (1.9 KLOC).

Generalmente, las aplicaciones no son monolíticas, sino que estánconstituidas por varios componentes ejecutables agrupados general-mente por funcionalidades. Esto permite replicar el mecanismo endiferentes componentes, lo cual aumenta sustancialmente el número

7.3 evaluación de la disponibilidad 151

de nodos, mientras que el impacto global se mantiene en márgenesajustados.

7.3.2 Sobrecarga del tiempo de ejecución

A partir de los resultados obtenidos en epígrafe 7.1.3, se pudo com-probar que el total de nodos de verificación y de respuesta incidendirectamente en la sobrecarga del tiempo de ejecución.

La sobrecarga del tiempo de ejecución se define como T1/T0 , dondeT1 es el tiempo de ejecución del software protegido con el mecanismono determinista y T0 es el tiempo de ejecución de con la proteccióndeterminista. El tiempo evaluado se corresponde solamente con eltiempo en el cual la aplicación hizo uso del procesador.

Dado que el número de nodos de verificación y de respuesta eje-cutados varía de una caso de prueba a otro, fue necesario evaluar lasobrecarga de ejecución para cada caso de prueba particular. Adicio-nalmente, se realizaron las pruebas con las diferentes configuracionesdel mecanismo de protección.

En la figura 48 puede verse la sobrecarga media de todos los casosde prueba para cada configuración. Como puede apreciarse el incre-mento medio en los tiempos de ejecución no supera en ningún casoel 12 %.

1 11971,12

1,1064

1,1197

1,08

ga media

1,0711

Sobrecarg

1,04

1,0269 1,0269

1 001,00

C1 C2 C3 C4 C5

Configuracioneso igu a io e

Figura 48 Sobrecarga de tiempo medio de todos los casos de prueba paracada configuración.


Del total de 58 casos de prueba ejecutados, en 51 casos de prueba(87.93 %) no se apreció impacto alguno sobre el rendimiento del soft-ware, ya fuese con el comportamiento determinista o no determinista.Esto se debe fundamentalmente a la distribución homogénea del me-canismo de protección a lo largo de todo el software. En la figura 49

se muestran los resultados para los peores casos (el 12.17 % restante).

3,0

2,5

2,0

1,5

mpacto C1

C2

1,0

Im

C3

C4

0

1,0 C4

C5

0,5

0,0

Cp 1 Cp 2 Cp 8 Cp 9 Cp 25 Cp 26 Cp 46

Casos de prueba

Figura 49 Sobrecarga del tiempo de ejecución para los casos por encima dela media.

Como era de esperar, el impacto se hace mayor a medida que au-menta el número de nodos. En el peor caso el impacto es de 2.5 (casode prueba 2, configuración C5), aunque es necesario destacar queocurre en el orden de los milisegundos.

Al igual que en la sobrecarga del tamaño, el tiempo adicional estádado por la ejecución del generador de números pseudo aleatorios.

A la vista de los resultados se concluye que, a pesar de utilizar unesquema de inserción estático para la red (inserción proporcional altamaño de los métodos, ver algoritmo 3), el impacto es despreciableen la mayoría de los casos. La reducción del impacto en los peorescasos se podría conseguir combinando el esquema de inserción está-tico con otro dinámico que tuviera en cuenta los distintos casos deprueba.


7.4 evaluación de la seguridad

En el presente epígrafe se realiza una evaluación experimental de laseguridad del mecanismo de protección. Para ello se simula el com-portamiento de un atacante y se aplica el modelo de evaluación pro-puesto en el capítulo 5. La realización del experimento tiene dos ob-jetivos fundamentales:

1. Analizar la seguridad del mecanismo de protección para dife-rentes configuraciones.

2. Comparar la seguridad alcanzada respecto a un mecanismo deprotección equivalente con comportamiento determinista.

En las siguientes secciones se describen los experimentos realiza-dos. Inicialmente se realiza una planificación del experimento. Pos-teriormente se emplea el árbol de ataque propuesto para evaluar laseguridad de distintas configuraciones del mecanismo de protección.En cada caso se estima el peso del nodo en el árbol y finalmente serealiza una estimación general del ataque respecto a un mecanismodeterminista equivalente.

En todo momento se trata de hacer una evaluación de peor escena-rio, esto es evaluar el ataque más efectivo frente a la protección mástrivial.

7.4.1 Planificación del experimento

Para el experimento se empleó el software de compresión de datosgzip antes mencionado. Los experimentos fueron llevados a cabo so-bre la misma arquitectura de hardware antes referida. La compilacióne inserción del mecanismo de protección en el software de prueba,fue llevado a cabo mediante los componentes de protección de la SPIdescritos en la sección 6.5 del capítulo 6. Como promedio, el impac-to en el tiempo de compilación del software protegido respecto a lacompilación sin protección, es de sólo un 3 %.


Los experimentos relacionados con la evaluación de la coberturade código, se realizaron con la herramienta de perfilado de MicrosoftVisual Studio 2008

6.Para determinadas configuraciones del mecanismo de protección,

la realización del experimento real puede presentar los siguientes in-convenientes:

1. Tiempo excesivo de realización. Una configuración adecuadadel mecanismo de protección que maximice el tiempo de ata-que, implica un coste significativo en tiempo para obtener losresultados del experimento, haciéndolo inviable.

2. Baja calidad de los resultados. Una configuración más simpledel mecanismo de protección permite obtener los resultados ex-perimentales en un tiempo razonable, pero no mostraría debi-damente la robustez del mecanismo de protección.

Lo deseable es que el experimento para estimar el coste de un ata-que pueda ser realizado en un tiempo razonable y que permita re-petirlo para varias configuraciones del mecanismo de protección. Poreste motivo, en lugar de realizar un experimento real sobre el softwa-re de prueba, se ejecutó sobre un simulador de precisión suficiente ycapaz de garantizar ambas condiciones.

Para este fin se diseñó un simulador que implementa los algoritmosde ataque referidos en el capítulo 5, específicamente el de localización(algoritmo 5, página 86) y validación de la manipulación (algoritmo7, página 91).

El simulador tiene como entrada los siguientes parámetros:

1. Características esenciales del software de prueba.

• Número de casos de prueba.

• Tiempo asociado a la ejecución del software para cada ca-so.

2. La configuración del mecanismo de protección.

• Número de nodos de verificación.

6 Command-Line Profiling Tools Reference (http://msdn.microsoft.com/en-us/library/bb385768%28v=vs.90%29.aspx).

http://msdn.microsoft.com/en-us/library/bb385768%28v=vs.90%29.aspx

http://msdn.microsoft.com/en-us/library/bb385768%28v=vs.90%29.aspx


• Probabilidad global de respuesta de cada nodo para cadacaso de prueba.

3. Parámetros del ataque:

• Umbral de localización y de comprobación.

• Tiempo estimado localización de una respuesta y la depu-ración inversa.

• Tiempo estimado de la manipulación de un nodo.

Toda esta información es suministrada al simulador mediante ar-chivos de configuración. Esto permite variar los parámetros y realizarsimulaciones para distintas configuraciones del mecanismo de protec-ción. El simulador brinda como salida el coste de tiempo asociado aun ataque específico.

Evaluación del simulador

Para comprobar el correcto funcionamiento y precisión del simuladordesarrollado, se realizó un experimento previo sobre el software deprueba utilizando una red pequeña con la siguiente configuración(ver tabla 8).

pc pr C R H

Nivel 0.8 0.8 64 128 1

Tabla 8 Configuración del mecanismo de protección para validar la simula-ción.

Durante el experimento se calculó la probabilidad global de res-puesta de cada nodo para cada caso de prueba del software. Adicio-nalmente se evalúo el tiempo de ejecución del software para cadacaso de prueba. Esta información, unida al resto de las configuracio-nes definidas, fue suministrada al simulador y se procedió a estimary comparar el tiempo de localización de los nodos de verificación porambas vías.

La localización de los nodos se considera exitosa, cuando se loca-lizan todos los posibles nodos para un conjunto de casos de pruebadado. Por este motivo, se realizó inicialmente un experimento en el


cual se incrementa el umbral de localización, hasta localizar el 100 %de los nodos de verificación. De forma paralela, se evalúa el tiempode localización para cada umbral.

La tabla 9 muestra el porcentaje de nodos promedio localizadospara diferentes umbrales de localización, tanto en el experimento rea-lizado sobre la aplicación de prueba, como en la simulación.

Umbral de localización

1 2 4 8 16 32

Aplicaciónde prueba

51.88 68.38 82.13 89.15 98.21 100

Simulación 52.15 68.64 81.89 88.93 98.15 100

Tabla 9 Nodos Localizados ( %).

Adicionalmente, en la tabla 10 se muestra el tiempo de localizaciónequivalente para cada umbral.

Umbral de localización

1 2 4 8 16 32

Aplicaciónde prueba

0.44 0.64 0.77 0.87 1.01 1.12

Simulación 0.41 0.66 0.74 0.86 0.99 1.14

Reducciónde tiempo

80 % 80 % 80 % 80 % 80 % 80 %

Tabla 10 Tiempo de localización (horas).

Se puede apreciar que los resultados obtenidos al ejecutar el expe-rimento sobre el software de prueba y la simulación son equivalentes.Las diferencias entre los resultados están dadas por el no determinis-mo del mecanismo de protección. La validación del funcionamientodel simulador, basada en la comparación de medias a través de unaprueba t de dos muestras independientes, puede ser vista en el anexoD. Como promedio se logra una reducción del 80 % del tiempo delexperimento al emplear el simulador. Teniendo en cuenta que estosdatos se obtuvieron para una configuración relativamente sencilla, la


utilización del simulador en la experimentación con configuracionesmás realistas se vuelve imprescindible.

7.4.2 Casos de prueba

Generación del conjunto de casos de prueba

Para la generación de los casos de prueba se dispuso del código fuen-te de la aplicación de prueba (gzip). De forma manual se generó unperfil de mejor caso de cobertura de código (por encima del 80 %),con un total de 58 casos de prueba para lo cual se necesitaron unas36 horas trabajo. La figura 50 muestra este perfil en el que se puedeapreciar un 82 % de cobertura de código, un 8 % de código parcial-mente cubierto y un 10 % sin cubrir. Esto implica la posibilidad deque los nodos de verificación albergados en la zona no cubierta o par-cialmente cubierta, no sean ejecutados durante un análisis dinámico.

10% Cubierto

Parcialmente cubierto8% Parcialmente cubierto

No cubierto

82%

Figura 50 Cobertura de código del software de prueba.

En la gráfica 51 se muestra el porcentaje de nodos que no fueronejecutados para ningún caso de prueba.

Como se puede apreciar, el porcentaje de nodos puede llegar aser alto. Por ejemplo, para una red de 1024 nodos de verificación,alrededor de 279 nodos (27.25 %) no fueron ejecutados. Esto implicaque el atacante puede dar por eliminado el mecanismo de proteccióncuando esto no es cierto.


17,97%

24,22%

27,93% 27,25%

20%

25%

30%

Nodos no cubiertos

15,63%

5%

10%

15%

0%

C1 C2 C3 C4 C5

Configuraciones

Figura 51 Porcentaje de nodos no cubiertos por los casos de prueba.

Minimización y priorización del conjunto de casos de prueba

Como se estableció en el epígrafe 5.1.1 del capítulo 5, la minimiza-ción puede llegar a ser tanto o más costosa que el empleo de loscasos de prueba sin minimizar, por lo que se optó por no realizar laminimización. Por otro lado, siguiendo con la filosofía de generar elpeor escenario (más favorable al atacante), se priorizaron los casos deprueba en función de la cobertura proporcionada. Las gráficas de dis-persión de la figura 52 muestra la relación del porcentaje de códigono cubierto y el porcentaje de nodos de verificación ejecutados, paradistintos números de nodos de verificación insertados en la aplicaciónde prueba.

En la tabla 11 se muestran los valores del coeficiente de correlaciónde Pearson entre ambas variables, para los distintos totales de nodosde verificación.

Se puede apreciar que la correlación entre ambas variables es fuer-te, siendo inversamente proporcionales entre sí, lo que muestra launiformidad en la distribución de la protección.

El tiempo de empleado para la priorización de los casos de pruebaen este caso es despreciable, dado que el conjunto es pequeño y solose tuvo en cuenta un factor para su priorización.


10090807060

50

40

30

20

10

0

Código no cubierto (%)

No

do

s e

jecu

tad

os (

%)

(a) 64 nodos.

10090807060

40

30

20

10

0


No

do

s e

jecu

tad

os (

%)

(b) 128 nodos.

10090807060

40

30

20

10

0


No

do

s e

jecu

tad

os (

%)

(c) 256 nodos.

10090807060

35

30

25

20

15

10

5

0

Codigo no cubierto (%)

No

do

s c

ub

iert

os (

%,

T 5

12

)

(d) 512 nodos.

10090807060

35

30

25

20

15

10

5

0


No

do

s e

jecu

tad

os (

%)

(e) 1024 nodos.

10090807060

30

25

20

15

10

5

0


No

do

s e

jecu

tad

os (

%)

(f) 2048 nodos.

Figura 52 Gráfica de dispersión de cobertura de código y ejecución de no-dos.

Total de nodos de verificación

64 128 256 512 1024 2048

Coheficiente decorrelación

−0.98 −0.98 −0.98 −0.98 −0.97 −0.99

Tabla 11 Coeficientes de correlación de cobertura de código y ejecución denodos.


7.4.3 Localización de los nodos de verificación

Generación del oráculo de prueba y depuración inversa

La generación del oráculo de prueba se realizó acorde al algoritmo 4

teniendo como entrada los 58 casos de prueba generados previamen-te. El tiempo para la generación del oráculo en este caso es desprecia-ble.

El procedimiento para la localización de los nodos de verificaciónfue llevado a cabo mediante el algoritmo de depuración inversa pre-viamente propuesto (ver algoritmo 5, página 86). Para el análisis, seasumió que el tiempo de localización de la respuesta y la realizaciónde una depuración inversa hasta el nodo de verificación puede servariable, por lo que se representa mediante la variable TDI

7.De este algoritmo se desprende que el atacante invierte un mayor

esfuerzo mientras: (1) sea mayor el número de nodos, (2) sea mayorel número de casos de prueba, (3) sea menor la cantidad de casosde pruebas que activen cada nodo de forma independiente y (4) seamayor el umbral de ataque (condicionado por la probabilidad de ob-tenerse una respuesta para cada caso de prueba). De estos factores, el1 y el 4 pueden ser configurados de forma adecuada en el mecanis-mo de protección, no sucediendo así con el 2 y 3, que dependen deparámetros de la aplicación a proteger.

A partir del simulador desarrollado previamente, se procedió a rea-lizar una simulación para estimar el tiempo de localización de losnodos. Inicialmente, es necesario calcular el umbral requerido paralocalizar todos los nodos de verificación con un nivel de confianzadel 99 %. En la tabla 12 se muestran los resultados obtenidos. Es ne-cesario destacar que el umbral de localización es independiente delnúmero de nodos y su valor sigue una distribución geométrica (verepígrafe 5.2.3 de la página 97).

7 En (Piazzalunga et al., 2007) se realiza una evaluación experimental de la seguri-dad de un mecanismo de protección basado en Dongle. Los autores en calidad deatacantes, plantean que cuando las respuestas no están ofuscadas y la distancia es-pacial entre la verificación y la respuesta es corta, el tiempo de localización es de 10

minutos.


Probabilidades

0.01 0.001 0.0001

Umbral (experimental) 512 4096 32768

Umbral (teórico) 459 4606 46050

Tabla 12 Umbral de localización requerido para localizar los nodos de veri-ficación.

En el caso de un mecanismo de protección determinista, el umbrales 1 dado que las respuestas son obtenidas con total nivel de certeza.A medida que disminuye la probabilidad de respuesta, aumenta elumbral requerido para la localización.

Una vez estimado el umbral, se procedió a estimar el tiempo delocalización de los nodos. En la tabla 13 se puede observar los resul-tados obtenidos, los cuales están expresados de forma relativa al casodeterminista.

Configuraciones

PR C1 C2 C3 C4 C5

0.01 3.58 4.57 5.80 7.00 7.83

0.001 24.23 32.28 41.55 56.83 70.36

0.0001 217.51 295.43 388.77 516.84 612.36

Tabla 13 Coste asociado de la localización de los nodos de verificación rela-tivo al caso determinista.

Se puede apreciar que el tiempo de localización aumenta a medidaque (1) aumenta el número de nodos y (2) disminuye la probabilidadde respuesta. Como se puede apreciar, de forma general, el coste aso-ciado aumenta un orden de magnitud para el caso de PR=0.001 y dosórdenes para el caso PR=0.0001. De esta forma, el tiempo máximode localización se obtiene para la configuración C5 y una probabili-dad de respuesta igual a 0.0001. Si asignamos un minuto a la variableTDI (mucho menor que los 10 minutos referidos en Piazzalunga et al.,2007), el tiempo de localización sería de 320 días aproximadamente,por lo que se impone un coste significativo en el ataque.


Estos resultados evidencian la fortaleza del mecanismo de protec-ción no determinista frente al determinista, para una misma configu-ración del mecanismo de protección ante un ataque dinámico.

7.4.4 Manipulación de los nodos de verificación

Para realizar una evaluación del coste de este ataque, se asigna untiempo de manipulación mediante la variable TM.

En este caso, el coste de manipulación está condicionado solamentepor el número de nodos de verificación que fueron localizados.

Dado que el no determinismo no incide en el coste real de la mani-pulación, no es necesario tener en cuenta dicho valor al realizar unacomparación respecto a un mecanismo de protección deterministaequivalente.

7.4.5 Comprobación de la manipulación

La comprobación de la manipulación realizada se llevó a cabo me-diante el algoritmo de validación propuesto (ver algoritmo 7, página91), asumiendo el peor escenario, es decir, que la manipulación serealizó satisfactoriamente para cada nodo localizado (por tanto no seobtendría respuesta alguna para cada caso de prueba).

Al igual que en la localización, se procedió a estimar el tiempode comprobación mediante una simulación. El coste de este ataquepuede ser variable, dado que depende fundamentalmente del umbralde comprobación establecido por el atacante y el número de casos deprueba.

Tomando como referencia los valores de umbral obtenidos duran-te la localización (ver tabla 12), se procedió a estimar el tiempo decomprobación de la manipulación. Los resultados relativos al casodeterminista pueden ser vistos en la tabla 14.

De forma general, el coste de la comprobación aumenta a medidaque crece el número de nodos de verificación y disminuye la proba-bilidad de respuesta. El sobrecoste alcanza dos órdenes de magnitudpara PR=0.01, tres órdenes para PR=0.001 y cuatro órdenes de mag-nitud para PR=0.0001.

7.5 proceso de config . del mecanismo de prot. 163

Configuraciones

Probabilidadesde respuesta

C1 C2 C3 C4 C5

0.01 355.6 444.4 481.5 555.6 592.6

0.001 2777.8 3592.6 3888.9 4777.8 5777.8

0.0001 25666.7 33481.5 36814.8 43703.7 51888.9

Tabla 14 Coste asociado a comprobación de la manipulación relativo al casodeterminista.

7.5 proceso de configuración del mecanismo de protec-ción

A partir de los resultados obtenidos en los experimentos realizados,se identificaron los factores significativos y los niveles que influyen enla seguridad y disponibilidad del mecanismo de protección (ver tabla15). La probabilidad de respuesta global PR no puede ser controladadirectamente, por lo que en su lugar, se ajustan los factores pc y pr.

PRC R

pr pc

Ofuscación (O) b b a a

Esfuerzo del atacante (EA) b b a a

Sobrecarga de Tiempo (ST) i i b b

Sobrecarga de Código (SC) i i b b

a: alto, b: bajo, i: indiferente

Tabla 15 Factores influyentes en la seguridad y disponibilidad del mecanis-mo de protección.

La configuración es la misma para maximizar la ofuscación y elesfuerzo requerido por el atacante. Sin embargo, esta contradice laconfiguración requerida para minimizar el impacto en la sobrecargade tiempo y código.

Con el objetivo de permitir al usuario de la SPI obtener las me-jores soluciones de compromiso entre las restricciones especificadas,


se propone el proceso de exploración del espacio de configuracionesque puede verse en la figura 53).

Proceso de Configuración

<<goal>>Configurar el mecanismo de

protección

<<physical>>Programa

<<people>>Usuario SPI

C,R

<<control>> <<achieve>>

<<supply>>

<<physical>>Simulador

<<supply>>

<<physical>>Casos de prueba

<<supply>>

<<information>>

Restricción

<<information>>

Configuración

ST SC EA

Fijar PR

Estimar esfuerzo del

atacantePR

ST

SC

EAe

Fijar C, R

EAe < EA

PR EA

prpc

pc prC R

Figura 53 Proceso de configuración del mecanismo de protección.

Inicialmente se fija la cantidad de nodos de verificación y respues-ta, de forma tal que la sobrecarga de tiempo y código impuesta seaaproximadamente igual a la especificada. En este punto se satisfacelas restricciones de sobrecarga, a la vez que se alcanza cierto nivel deseguridad. Posteriormente se fija PR a través de pc y pr, y se procedea calcular el esfuerzo requerido por el atacante mediante una simu-lación. Si el esfuerzo estimado del atacante (EAe) es menor que elespecificado por el usuario, se pasa nuevamente a disminuir PR paraaumentar la seguridad, pues no es posible aumentar el número denodos de verificación dada la restricción de sobrecarga.

En el algoritmo 8, se muestra un ejemplo de diseño del procesode configuración con un mayor nivel de detalle para cada uno de lossubprocesos especificados.

La primera restricción que se satisface es la sobrecarga de código(líneas 1–6). Para ello se agregan nodos al conjunto C y R mientrasque la sobrecarga de código estimada (SCe) calculada sea menor a laespecificada por el usuario.

Posteriormente se verifica la restricción de sobrecarga de tiempo(líneas 7–12). Para cada caso de prueba (ei), se elimina un subconjun-to de nodos de C y R hasta que la sobrecarga de tiempo estimada(STe) sea menor que la especificada. Para la estimación de sobrecarga,

7.5 proceso de config . del mecanismo de prot. 165

se toma como referencia el tiempo de ejecución asociado al caso deprueba (ti) antes de aplicar la protección.

Algoritmo 8: Configuración del mecanismo de protección.entrada :SC, ST , EA, P, E = {〈e1, t1〉, 〈e2, t2〉, . . . , 〈en, tn〉}salida :C, R, pc, pr

// Fijar C, R

1 C,R← ∅;2 SCe ← 0;3 while SCe < SC do4 C← C∪ {ci1, . . . , cin} | n = δ;5 R← R∪ {ri1, . . . , rim} | m = 2n;6 SCe ← CalcImpactCod(P,C,R);

7 foreach ei ∈ E do8 STe ← CalcImpactTiemp(P, 〈ei, ti〉, C, R);9 while STe > ST do

10 C← C− {ci1, . . . , cin} | n = γ;11 R← R− {ri1, . . . , rim} | m = 2n;12 STe ← CalcImpactTiemp(P, 〈ei, ti〉, C, R);

13 pc,pr,PR← 1;14 EAe ← 0;15 while EAe < EA do

// Fijar PR

16 disminuir PR;17 foreach ci ∈ C do18 Manipular(ci);19 foreach ej ∈ E do20 PRe ← Ejecutar(P, ej, pc, pr);21 while PRe > PR do22 disminuir pc;23 disminuir pr;24 PRe ← Ejecutar(P, ej, pc, pr);

// Estimar esfuerzo del atacante

25 (o,h)← CalcularOfusc(PR);26 EAe ← SimLocalizacion(E, |C|, PR, h);27 EAe ← EAe+ SimComprobacion(E, PR, h);

Una vez determinado los conjuntos C y R que satisfacen las restric-ciones SC y ST , se pasa a fijar el valor de PR (líneas 16–24). Se parte


de un estimado inicial (PRe) y se disminuyen los valores de pc y prpara todos los nodos y casos de prueba, hasta que sea menor que elPR de referencia, esto es, ∀ci ∈ C,∀ej ∈ E : PRe(ci, ej) < PR.

El PR de referencia es empleado posteriormente para estimar elesfuerzo del atacante (líneas 25–27). Inicialmente se calcula el nivelde ofuscación alcanzado y se determina el umbral de ataque (h), elcual es empleado para estimar el esfuerzo del ataque (EAe) mediantela simulación de localización y comprobación. Si el EAe calculado esmenor que el establecido por el usuario (linea 15), se disminuye el PRde referencia (línea 16) y se pasa nuevamente a ajustar los valores depc y pr.

7.6 conclusiones

En este capítulo se abordó la evaluación experimental de la seguri-dad y el rendimiento del mecanismo de protección no deterministapropuesto.

En primer lugar, se pudo comprobar el correcto funcionamiento dela implementación del componente automatizado de protección queforma parte de la propuesta de la SPI. Al respecto, la sobrecarga deltiempo de compilación impuesto por la inserción del mecanismo deprotección fue baja.

El primer objetivo a lograr con los experimentos fue la identifica-ción de una adecuada configuración del mecanismo de protección.Para ello se aplicó un diseño de experimento factorial, que permi-tió obtener los resultados de forma eficiente y rigurosa. El análisisrealizado sobre los valores influyentes y sus interacciones permite alusuario de la SPI tomar las decisiones adecuadas a la hora de con-figurar el mecanismo de protección en pos de obtener el requeridocompromiso entre seguridad y disponibilidad.

Para evaluar la seguridad y disponibilidad del software protegido,se desarrolló y validó un simulador de prueba, que permitió abaratarlos costes de la obtención de los resultados experimentales en cuantoa la seguridad y fuga de información, a la vez que se mantuvo lafidelidad de los resultados obtenidos.

Durante la experimentación, se probaron un total de veinte confi-guraciones diferentes del mecanismo de protección. Los resultados

7.6 conclusiones 167

obtenidos muestran una mejora sustancial en cuanto a la seguridad ynivel de ofuscación alcanzado respecto al caso determinista. Sin em-bargo, el impacto en el tamaño y el rendimiento, es relativamentesuperior que el caso determinista.

De forma general, los resultados obtenidos permiten encontrar con-figuraciones de compromiso entre la seguridad, el nivel de fuga deinformación y el impacto en la disponibilidad del software protegido.Esto garantiza que se puedan identificar configuraciones que priori-cen un elemento u otro.

8C O N C L U S I O N E S Y T R A B A J O S F U T U R O S

8.1 conclusiones generales

La arquitectura insegura de los procesadores convencionales ha per-mitido que un número creciente de atacantes comprometan los atri-butos de seguridad de los componentes de software comercializados,en especial, la privacidad e integridad de los mismos.

Las pérdidas millonarias por concepto de piratería de software($63.4 billones de dólares en el 2011) han propiciado un interés mar-cado en la investigación y en el desarrollo de soluciones para la pro-tección de componentes de software.

La problemática de la protección de componentes de software enun ambiente de ejecución no confiable se considera un problemaabierto de investigación, observándose un conjunto amplio y diver-so de investigaciones sobre el tema.

La técnica de auto-verificación de integridad como una vía paraofrecer, en cierto grado, resistencia ante ataques dinámicos de in-geniería inversa, está identificada como una solución viable a estosproblemas. Sin embargo, se requiere aplicar mecanismos de ofusca-ción adicionales que garanticen la privacidad de dicha técnica. Estacombinación de enfoques contribuye a alcanzar un mayor grado deprotección.

Las propuestas analizadas conciben en su mayoría una ofuscaciónestructural, lo cual no es suficiente para ofrecer alta resistencia anteataques dinámicos, siendo necesario aplicar técnicas de ofuscaciónfuncional (semántica) para alcanzar este fin.

Se ha identificado además, como otro problema esencial, la necesi-dad de automatizar el proceso de protección con el objetivo de hacer

169

170 conclusiones y trabajos futuros

viable su uso en el proceso de desarrollo de software en el que, enmuchas ocasiones, se obvia la satisfacción de los atributos de seguri-dad.

Adicionalmente, la mayoría de las propuestas no evalúan de for-ma cuantitativa el nivel de seguridad conseguido, por lo que resultadifícil determinar el nivel de resistencia que pueden ofrecer ante unataque.

Por todo esto, la presente investigación se centró en la propuestade un modelo no determinista para la auto-verificación de integridad,capaz de ofrecer alta resistencia ante ataques dinámicos de ingenieríainversa, automatizable y que no atenta negativamente sobre la dispo-nibilidad del componente de software a proteger.

Se introduce un modelo para la evaluación de la seguridad, el cualcuantifica, para una configuración dada, el esfuerzo requerido porun atacante en desactivar el mecanismo de protección, a la vez que seevalúa el nivel de ofuscación alcanzado.

Se argumenta, sobre un principio de seguridad práctica, que el ata-cante está en una situación de muy alta incertidumbre sobre la efecti-vidad de sus acciones cuando la información mutua del canal (com-ponente protegida) es cero, lo que equivale a decir que la componentese comporta como una fuente discreta de entropía máxima.

En una situación de alta incertidumbre, el atacante se verá obligadoa reiterar el número de ataques e intentar desactivar completamentela red de auto-verificación de integridad, lo que, en situaciones prác-ticas, puede consumirle notables recursos y un tiempo superior altranscurrido desde el lanzamiento del producto hasta el inicio de laetapa de declive.

La base conceptual anteriormente descrita puede ser verificada me-diante la experimentación, planteándose diferentes estrategias y refi-namientos que permitan dotar a una componente de software de unmecanismo de auto-verificación de integridad y un comportamientono determinista suficientemente confiable.

De esta forma, una instancia específica de ofuscación del mecanis-mo de auto-verificación de integridad puede ser evaluada atribuyén-dole una medida de calidad a partir de su cercanía a un modelo decomportamiento ideal con respuestas equiprobables y la superiori-

8.2 principales aportaciones 171

dad con respecto a una solución basada en una red determinista conla misma configuración.

El resultado práctico de la investigación se concreta en un prototipofuncional del modelo de auto-verificación de integridad y su aplica-ción automatizada sobre la componente de software a proteger. Sobreel mismo se desarrolló una evaluación experimental de la propuesta,aplicando el modelo de evaluación de la seguridad referido.

La investigación complementa el planteamiento teórico con unapropuesta de infraestructura que permitiría concebir una arquitec-tura de software en el que estos mecanismos de protección fuesenbrindados como servicios a clientes interesados y cuyo conocimientose restringiría al modelo de negocio de la componente desarrollada.

Este enfoque permitiría, además de una alta especialización, unafrontera bien establecida entre el conocimiento de los desarrolladoresde software y los de soluciones de seguridad, aspecto en el que senecesita propiciar el trabajo multidisciplinario.

En las secciones siguientes se hace énfasis en las principales apor-taciones alcanzadas durante la investigación y los problemas abiertosy líneas de trabajo futuro identificadas.

8.2 principales aportaciones

Las aportaciones de la investigación doctoral desarrollada se enmar-can en las siguientes dimensiones:

8.2.1 Dimensión teórica

• Propuesta de un modelo que combina ofuscación y auto-verifica-ción de integridad que consigue aumentar el esfuerzo necesariopara concretar un ataque dinámico con éxito.

• Propuesta novedosa de aplicación del concepto de canal de co-municaciones discreto y la teoría de la información a la evalua-ción del nivel de ofuscación del modelo de protección.


8.2.2 Dimensión de evaluación del planteamiento teórico

• Propuesta de árbol de ataque que permite evaluar el coste tem-poral de un ataque exitoso.

• Propuesta de una métrica relacionada con la fuga de informa-ción para cuantificar y comparar el grado de ofuscación de dis-tintas técnicas basadas en el esquema pregunta-respuesta.

• Evaluación del modelo de red AVI no determinista mediante lacombinación del árbol de ataque y la métrica de fuga de infor-mación.

8.2.3 Dimensión práctica

• Propuesta de una infraestructura para la protección de software,donde se cubre todo el ciclo de desarrollo de los componentesde protección y su aplicación automatizada en el proceso dedesarrollo de software.

• Desarrollo de una implementación de la infraestructura basadaen el mecanismo de redes de auto-verificación de integridad nodeterministas.

• Propuesta de directrices para la consecución de soluciones decompromiso en el diseño de redes AVI no deterministas.

8.3 publicaciones

A lo largo del desarrollo de la presente tesis se realizaron las siguien-tes publicaciones científicas:

• Artículos en revistas científicas:

– Yulier Nuñez Musa, Roberto Sepúlveda Lima, Sergio Cuen-ca Asensi, Itzamá López Yáñez, and Luis Octavio López Ley-va.A non-deterministic self-checking mechanism to enhan-ce tamper-resistance in engineering education software. In-ternational Journal of Engineering Education, 28(6):1393–1398,2012.

8.4 trabajo futuro 173

• Conferencias científicas:

– Humberto Díaz Pando, Yulier Nuñez Musa, Roberto Sepúl-veda Lima, y Sergio Cuenca Asensi. Tendencias actuales enla concepción de subsistemas hardware para la protecciónde aplicaciones. En IX Seminario Iberoamericano de Seguri-dad en las Tecnologías de la Información, La Habana, Cuba,febrero 9–13 2009.

– Yulier Nuñez Musa, Roberto Sepúlveda Lima, HumbertoDíaz Pando, y Sergio Cuenca Asensi. Redes híbridas parala autoverificación de integridad de aplicaciones. En Desa-rrollo de Grandes Aplicaciones de Red VI Jornadas, Alicante,España, octubre 15-16 2009a.

– Yulier Nuñez Musa, Roberto Sepúlveda Lima, HumbertoDíaz Pando, y Sergio Cuenca Asensi. Redes de autove-rificación de integridad no deterministas para mejorar laresistencia ante la modificación de software. En Desarro-llo de Grandes Aplicaciones de Red VII Jornadas, pages 61–73,Alicante, España, octubre 14–15 2010.

Por otra parte, los resultados de esta tesis han sido aplicados par-cialmente en el Proyecto de Seguridad Tecnológica, llevado a cabo en elComplejo de Investigaciones Tecnológicas Integradas - CITI en colabora-ción con la Facultad de Ingeniería Informática perteneciente a la CUJAE.

8.4 trabajo futuro

Al concluir esta investigación se vislumbran los escenarios de trabajofuturo relacionados con las dimensiones teórica, de evaluación delplanteamiento teórico y práctica.

8.4.1 Dimensión teórica

• Explorar vías para aumentar la tolerancia a ataques, previen-do la introducción de capas de interconexión de varios nivelesentre la capa de verificación y la capa de respuesta.

El modelo planteado se enmarca en la existencia de una com-ponente de verificación y una capa de respuesta. Es presumible


que, en determinadas circunstancias, sea necesario mejorar losniveles de ofuscación y la tolerancia de la componente a ata-ques.

La incorporación de elementos de redundancia de activaciónpodrían aumentar el no determinismo del modelo y con ello,alcanzar una mejor ofuscación.

• Definir otras componentes de autonomía y reactividad ante ata-ques. Es decir, introducir cierta dependencia funcional entre lasprobabilidades de respuesta de cada nodo y el dinamismo delos ataques recibidos y el comportamiento de la aplicación.

8.4.2 Dimensión de evaluación del planteamiento teórico

• Emplear canales en serie (teoría de la información) para evaluarpropuestas de capas de interconexión de n niveles.

• Modelar la propuesta como un proceso estocástico, en corres-pondencia con el empleo de probabilidades variables.

8.4.3 Dimensión práctica

• Desarrollar un modelo de negocio para brindar servicios de pro-tección de software, mediante la implementación de funcionescomplementarias en la fase intermedia de compilación a fin desustentar múltiples lenguajes de programación, sistemas opera-tivos y arquitecturas de procesadores.

• Estudiar estrategias de inserción basadas en las característicasdinámicas de la aplicación, lo que permitirá influir tanto en lasobrecarga del tiempo como en la probabilidad global de res-puesta.

AE L E M E N T O S D E L A T E O R Í A D E L A I N F O R M A C I Ó N

a.1 entropía de shannon

Sea X una variable aleatoria discreta con una alfabeto X y una distri-bución de probabilidad p (x) = P (X = x), x ∈ X. La entropía H (X) deuna variable aleatoria discreta X está definida por:

H (X) =∑x∈X

p (x) log1

p (x)(26)

La entropía es la medida de la incertidumbre de una variable alea-toria. Puede ser interpretada además como el valor esperado de unavariable aleatoria X con distribución de probabilidad p (x). La entro-pía no depende del valor actual tomado por la variable aleatoria X,sino de las probabilidades de esta.

A menos que se especifique de otro modo, la base del logaritmo es2, por lo que la medida de la entropía se expresa en bits. La entropíatoma su valor máximo log | X | cuando X distribuye uniformementey su valor mínimo 0 cuando X es constante (p (x) =0 o 1).

a.2 entropía condicional y entropía conjunta

Anteriormente se definió la entropía de una sola variable aleatoria. Sehace necesario extender esta definición a un par de variables aleato-rias X, Y.

175

176 elementos de la teoría de la información

La entropía conjunta H (X, Y) de un par de variables aleatorias dis-cretas (X, Y) con una distribución conjunta p (x,y) se define como:

H (X, Y) =∑x∈X

∑y∈Y

p (x,y) log1

p (x,y)(27)

Por otra parte, se define como entropía condicional de una varia-ble aleatoria dada otra variable, como el valor esperado de las entro-pías de las distribuciones condicionales, promediada sobre la variablealeatoria condicionada.

H (Y | X) =∑x∈X

p (x)H (Y | X = x) (28)

=∑x∈X

p (x)∑y∈Y

p (y | x) log1

p (y | x)(29)

=∑x∈X

∑y∈Y

p (x,y) log1

p (y | x)(30)

donde

p (y | x) =p (y, x)p (x)

(31)

a.3 información mutua

La información mutua es la medida de la cantidad de informaciónque una variable aleatoria contiene sobre otra variable aleatoria. Esla reducción de la incertidumbre de una variable aleatoria debido alconocimiento de la otra. Considere dos variables aleatorias X y Y conuna distribución de probabilidad conjunta p (x,y) y una distribuciónde probabilidad marginal p (x) y p (y). La información mutua I (X; Y)es la entropía relativa entre la distribución conjunta y la distribuciónproducto p (x)p (y):

A.3 información mutua 177

h

p (h,o) 0 1 2 3 p (o)

o0

1

0

1/4

1/4

0

0

1/4

0

1/4

1/4

3/4

p (h) 1/4 1/4 1/4 1/4 1

Tabla 17 Distribución de probabilidad conjunta p (h,o) de M1.

I (X; Y) =H (X) −H (X | Y) (32)

=∑x∈X

∑y∈Y

p (x,y) logp (x,y)p (x)p (y)

(33)

La obtención de 33 a partir de 32 puede ser vista en §2.4 de (Tho-mas M. Cover, 2006)

A continuación se muestra un ejemplo del cálculo de la informa-ción mutua basándose en la entropía de Shannon de un programasimple de autenticación M1:

M1 ≡ if (H == g) O = 0 else O = 1

En este caso, H es una variable aleatoria discreta y se correspondecon la entrada secreta al programa, siendo el espacio de las posiblescontraseñas a manejar por un usuario. Para simplificar el ejemplo, Htiene un tamaño de dos bits, por lo que la contraseña del usuariopuede estar en el rango H = {00, 01, 10, 11}. Concretamente g = 1 ysea P una distribución discreta uniforme1 sobre H, o sea, p (h) = 1

|H|

para cada h ∈ H. O es la salida observable del programa, con espacioO = {0, 1}y probabilidades p (o) = 1/4 para o = 0 y p (o) = 3/4 parao = 1. La distribución de probabilidad conjunta p (h,o) para cadah ∈ H y o ∈ O es la siguiente:

El cálculo de la información mutua entre H y O está dada por:

1 Tiene sentido considerar P una distribución discreta uniforme, dado que un usuariopodría elegir de forma equiprobable una contraseña del espacio H.


I (H;O) =∑h∈H

∑o∈O

p (h,o) logp (h,o)p (h)p (o)

(34)

=1/4 log 4+ 3 (1/4 log 4/3) (35)

≈0.8113 (36)

Un atacante habrá reducido su incertidumbre en 0.8 bits aproxima-damente sobre H una vez que haya observado O tras la ejecución deM1. Dicho de otra forma, el programa ha filtrado 0.8 bits de informa-ción secreta al atacante.

a.4 canal de comunicación

Un canal de comunicación o canal de información discreto2 está carac-terizado por un conjunto de entrada X = {x1, x2, . . . , xr}; un conjuntode salida Y = {y1,y2, . . . ,ys} y un conjunto de probabilidades con-dicionales P(yj | xi) (ver figura 54). P(yj | xi) es la probabilidad derecibir a la salida el símbolo yj cuando se envía el símbolo de entradaxi (Abramson, 1963).

j i

1

2

r

1

2

s

Figura 54 Canal de información.

El canal de comunicación puede ser descrito a partir de las proba-bilidades condicionales tal como se muestra en la tabla 18.

Cada fila se corresponde con una entrada xi siendo sus términoslas probabilidades condicionales de obtener las distintas yj para una

2 Se dice que un canal de información es de memoria nula si la distribución de proba-bilidad de la salida depende solamente en el momento de la entrada y es condicio-nalmente independiente de las entras o salidas previas del canal.

A.4 canal de comunicación 179

Salidas

Entradas

y1 y2 · · · ys

x1 P (y1 | x1) P (y2 | x1) · · · P (ys | x1)

x2 P (y1 | x2) P (y2 | x2) · · · P (ys | x2)

· · · · · · · · · · · · · · ·xr P (y1 | xr) P (y2 | xr) · · · P (ys | xr)

Tabla 18 Descripción de un canal de información.

entrada fija. Para simplificar la notación del canal de información sedefine:

Pij = P(yj | xi) (37)

A partir de 37 la tabla 18 se transforma en la matriz P

P =

P11 P12 . . . P1s

P21 P22 . . . P2s

. . . . . . . . . . . .

Pr1 Pr2 . . . Prs

(38)

De esta forma, un canal de información esta definido por su matrizP. Cada fila de la matriz se corresponde con una entrada del canal ycada columna a una salida. En la matriz P la suma de los elementosde una fila xi es igual a uno. Esta condición puede expresarse de laforma siguiente:

s∑j=1

Pij = 1 i = 1, 2, . . . , r (39)

Para un canal de r símbolos de entrada y s de salida, los símbo-los de entrada se eligen de acuerdo a sus probabilidades P(xi); i =1, 2, . . . , r. Los símbolos de salida aparecerán acorde a otro conjunto


de probabilidades P(yj); j = 1, 2, . . . , s). El cálculo de las las probabili-dades de salida (40) de cada P(yj) se obtienen a partir de las probabi-lidades de los símbolos de entrada P(xi) y la matriz del canal, o sea,la matriz de las probabilidades condicionales P(yj | xi).

P(y1) = P(x1)P11 + P(x2)P21 + . . .+ P(xr)Pr1 (40a)

P(y2) = P(x1)P12 + P(x2)P22 + . . .+ P(xr)Pr2 (40b)

P(ys) = P(x1)P1s + P(x2)P2s + . . .+ P(xr)Prs (40c)

Hay que destacar que a partir de las probabilidades de salida P(yj)y P(yj | xi) no puede calcularse las probabilidades de las entradasP(xi) invirtiendo el sistema de ecuaciones (40).

BI N F O R M A C I Ó N M U T U A D E L C A N A L

181

182 información mutua del canal

p

0.0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1.0

p(e)

0.0

00

00

00

00

00

0

0.1

0.469

0.39

0.33

0.2

78

0.2

30.

18

60.

14

50.

10

60.

069

0.0

34

0

0.2

0.722

0.586

0.49

0.4

08

0.3

35

0.2

69

0.2

08

0.1

51

0.0

98

0.0

48

0

0.3

0.881

0.701

0.578

0.4

77

0.3

89

0.3

10.

23

80.

17

20.

111

0.0

54

0

0.4

0.971

0.755

0.616

0.5

03

0.4

07

0.3

22

0.2

46

0.1

77

0.1

13

0.0

55

0

0.5

10.

758

0.61

0.4

93

0.3

96

0.3

11

0.2

36

0.1

69

0.1

08

0.0

52

0

0.6

0.971

0.714

0.566

0.4

53

0.3

60.

28

10.

21

20.

15

10.

096

0.0

46

0

0.7

0.881

0.622

0.484

0.3

83

0.3

02

0.2

34

0.1

76

0.1

25

0.0

79

0.0

38

0

0.8

0.722

0.48

0.365

0.2

85

0.2

22

0.1

71

0.1

28

0.0

90.

057

0.0

27

0

0.9

0.469

0.279

0.206

0.1

58

0.1

22

0.0

93

0.0

69

0.0

48

0.0

30.

01

40

1.0

00

00

00

00

00

0

Tabla19

Cálculo

deI(A

;R)

paradiferentes

valoresdep(e)

yp.

CR E S U LTA D O S D E L A E VA L U A C I Ó NE X P E R I M E N TA L

Exp. pc pr C R HPR

STN1 N2 N3

1 0.8 0.2 300 500 20 0.049 0.051 0.050 12.6

2 0.2 0.8 300 500 200 0.049 0.050 0.050 13.5

3 0.8 0.2 100 1500 20 0.040 0.045 0.044 13.2

4 0.8 0.8 300 500 20 0.198 0.195 0.191 12.5

5 0.2 0.8 100 500 20 0.047 0.049 0.048 8.9

6 0.2 0.8 100 1500 200 0.044 0.045 0.043 13.2

7 0.2 0.2 100 500 200 0.012 0.013 0.012 8.9

8 0.2 0.2 100 1500 200 0.012 0.012 0.011 13.6

9 0.2 0.2 100 500 200 0.011 0.014 0.014 8.9

10 0.8 0.2 100 1500 200 0.042 0.044 0.042 13.4

11 0.8 0.2 300 1500 20 0.037 0.042 0.037 14.2

12 0.2 0.2 100 500 20 0.012 0.013 0.012 8.9

13 0.8 0.2 100 500 200 0.048 0.048 0.048 9.2

14 0.2 0.8 300 1500 20 0.038 0.039 0.039 14.2

15 0.2 0.2 100 1500 200 0.011 0.009 0.011 13.1

16 0.8 0.8 100 500 200 0.192 0.193 0.192 9.0

17 0.2 0.2 300 1500 20 0.008 0.008 0.009 14.8

18 0.2 0.2 300 1500 200 0.010 0.010 0.010 14.8

19 0.2 0.2 300 500 200 0.012 0.013 0.012 12.8

20 0.2 0.2 300 500 200 0.013 0.011 0.014 12.3

21 0.8 0.8 300 1500 200 0.160 0.151 0.158 14.2

22 0.8 0.2 300 1500 200 0.040 0.043 0.040 14.8

183

184 resultados de la evaluación experimental

Exp. pc pr C R HPR

STN1 N2 N3

23 0.8 0.8 300 1500 200 0.153 0.155 0.159 14.9

24 0.8 0.8 100 500 20 0.194 0.187 0.190 8.8

25 0.2 0.8 100 1500 200 0.041 0.046 0.043 13.1

26 0.8 0.8 100 500 20 0.191 0.192 0.191 8.8

27 0.2 0.8 300 1500 20 0.039 0.040 0.039 14.8

28 0.2 0.2 100 1500 20 0.009 0.011 0.010 13.1

29 0.8 0.2 300 1500 200 0.035 0.040 0.039 14.3

30 0.2 0.8 100 1500 20 0.039 0.042 0.042 13.1

31 0.8 0.8 100 1500 200 0.171 0.171 0.162 13.5

32 0.2 0.8 300 500 20 0.049 0.047 0.052 12.5

33 0.2 0.2 300 1500 20 0.009 0.009 0.009 14.7

34 0.8 0.2 100 500 20 0.052 0.049 0.048 8.9

35 0.2 0.8 100 500 20 0.047 0.050 0.049 8.9

36 0.2 0.8 300 500 20 0.049 0.049 0.047 12.4

37 0.8 0.2 300 500 200 0.047 0.046 0.047 12.3

38 0.8 0.2 300 500 20 0.045 0.051 0.047 12.9

39 0.2 0.8 100 1500 20 0.039 0.042 0.041 13.1

40 0.2 0.2 100 1500 20 0.010 0.011 0.013 13.1

41 0.2 0.8 300 500 200 0.051 0.048 0.051 12.3

42 0.8 0.2 100 500 200 0.045 0.051 0.051 9.2

43 0.8 0.8 100 1500 20 0.167 0.164 0.160 13.1

44 0.2 0.8 300 1500 200 0.042 0.039 0.040 14.4

45 0.8 0.2 100 1500 200 0.043 0.039 0.042 13.7

46 0.8 0.8 300 1500 20 0.157 0.157 0.161 14.8

47 0.2 0.2 300 500 20 0.012 0.010 0.013 12.4

48 0.8 0.2 100 500 20 0.044 0.051 0.052 8.9

49 0.2 0.8 100 500 200 0.047 0.049 0.047 8.9

50 0.2 0.2 300 500 20 0.011 0.015 0.011 12.5

51 0.8 0.8 100 500 200 0.188 0.194 0.195 9.2

52 0.2 0.8 100 500 200 0.047 0.050 0.047 9.0

53 0.2 0.8 300 1500 200 0.037 0.039 0.043 14.4

54 0.8 0.8 300 500 200 0.187 0.195 0.203 12.5

55 0.8 0.8 300 500 200 0.192 0.190 0.191 12.9

56 0.8 0.2 300 1500 20 0.041 0.041 0.040 14.3

resultados de la evaluación experimental 185

Exp. pc pr C R HPR

STN1 N2 N3

57 0.8 0.8 300 500 20 0.189 0.189 0.191 12.9

58 0.2 0.2 300 1500 200 0.011 0.009 0.010 14.3

59 0.8 0.8 100 1500 200 0.162 0.169 0.173 13.3

60 0.8 0.2 100 1500 20 0.042 0.043 0.045 13.1

61 0.8 0.8 300 1500 20 0.160 0.157 0.156 14.8

62 0.8 0.8 100 1500 20 0.165 0.168 0.165 13.1

63 0.2 0.2 100 500 20 0.013 0.012 0.012 9.2

64 0.8 0.2 300 500 200 0.048 0.051 0.048 12.3

DVA L I D A C I Ó N D E L S I M U L A D O R

Para validar el correcto funcionamiento del simulador, se realiza unaprueba t de dos muestras independientes. El objetivo es esta pruebaes determinar si las medias de dos poblaciones independientes soniguales. Si el valor de p calculado en la prueba es menor que el nivelde significancia elegido, se debe rechazar la hipótesis nula.

En este caso, se compara los valores medios del porcentaje de nodoslocalizados y el tiempo de localización, para el software de prueba yel simulador. El tamaño de la población es de 150 en cada caso y elnivel de significancia α = 0.05.

La hipótesis para la comparación del porcentaje de nodos localiza-dos es:

• H0: µsoft − µsim = 0 (el porcentaje de nodos localizados esigual para el software de prueba y el simulador)

• H1: µsoft − µsim 6= 0 (el porcentaje de nodos localizados esdistinto para el software de prueba y el simulador)

Por otra parte, la hipótesis para la comparación del tiempo de loca-lización es:

• H0: µsoft − µsim = 0 (el tiempo de localización de los nodos esigual para el software de prueba y el simulador)

• H1: µsoft − µsim 6= 0 (el tiempo de localización de los nodos esdistinto para el software de prueba y el simulador)

En la tabla 21 se pueden apreciar los resultados obtenidos de laprueba t del porcentaje de nodos localizados, para los diferentes um-brales de localización (h). No fue necesario realizar la prueba para un

187

188 validación del simulador

umbral igual a 32, dado que para todas las muestras el porcentaje denodos localizado fue 100.

Umbral Media Desv. Est. p

Software1

51.88 1.32

0.074

Simulador 52.15 1.29

Software2

68.38 1.27

0.073


Software4

82.13 1.25

0.092


Software8

89.15 1.15

0.102


Software16

98.21 1.07

0.619


Tabla 21 Prueba t de dos muestras para el porcentaje de nodos localizados.

Los resultados obtenidos de la misma prueba para el tiempo delocalización, pueden verse en la tabla 22.

Umbral Media Desv. Est. p

Software1

0.44 0.12

0,091

Simulador 0.41 0.18

Software2

0.64 0.17

0,253

Simulador 0.66 0.13

Software4

0.77 0.13

0,065

Simulador 0.74 0.15

Software8

0.87 0.17

0,579

Simulador 0.86 0.14

Software16

1.01 0.18

0,259

Simulador 0.99 0.12

Software32

1.12 0.13

0,218

Simulador 1.14 0.15

Tabla 22 Prueba t de dos muestras para el tiempo de localización.

validación del simulador 189

Para ambos experimentos, todos los valores de p son mayores queel nivel de significancia elegido, por lo que no se encontró evidenciapara rechazar la hipótesis nula en cada caso. Los valores resumidospueden ser visto en la gráfica 55.

TiempoPorcentaje3216842132168421

0,7

0,6

0,5

0,4

0,3

0,2

0,1

0,0

p

0,05

0,619

0,1020,0920,0730,074

0,218

0,259

0,579

0,065

0,253

0,091

Figura 55 Valores de p de los experimentos.

B I B L I O G R A F Í A

A. Main, P. v. O. (2003). Software protection and application security:Understanding the battleground. In International Course on State ofthe Art and Evolution of Computer Security and Industrial Cryptography,Heverlee, Belgium.

Abramson, N. (1963). Information Theory and Coding. McGraw-Hill.

Alvim, M., Andrés, M., and Palamidessi, C. (2010). Entropy and at-tack models in information flow. In Calude, C. and Sassone, V.,editors, Theoretical Computer Science, volume 323 of IFIP Advancesin Information and Communication Technology, pages 53–54. SpringerBoston.

Anckaert, B., De Sutter, B., and De Bosschere, K. (2004). Softwarepiracy prevention through diversity. In DRM ’04: Proceedings of the4th ACM workshop on Digital rights management, pages 63–71, NewYork, NY, USA. ACM.

Anckaert, B., Jakubowski, M., Venkatesan, R., and De Bosschere, K.(2007). Run-time randomization to mitigate tampering. In Miyaji,A., Kikuchi, H., and Rannenberg, K., editors, Advances in Informa-tion and Computer Security, volume 4752 of Lecture Notes in ComputerScience, pages 153–168. Springer Berlin / Heidelberg.

Antony, J. (2003). Design of Experiments for Engineers and Scientists.Elsevier.

Ariss, O. E., Wu, J., and Xu, D. (2011). Towards an enhanced design le-vel security: Integrating attack trees with statecharts. In Proceedingsof the 2011 Fifth International Conference on Secure Software Integrationand Reliability Improvement, SSIRI ’11, pages 1–10, Washington, DC,USA. IEEE Computer Society.

Aucsmith, D. (1996). Tamper resistant software: An implementation.In Proceedings of the First International Workshop on Information Hi-ding, pages 317–333, London, UK. Springer-Verlag.

191

192 bibliografía

Backes, M., Kopf, B., and Rybalchenko, A. (2009). Automatic disco-very and quantification of information leaks. In Proc. 30th IEEESymp. Security and Privacy, pages 141–153.

Bang-Jensen, J. and Gutin, G. (2002). Digraphs: Theory, Algorithms andApplications. Springer.

Barak, B., Goldreich, O., Impagliazzo, R., Rudich, S., Sahai, A., Vad-han, S. P., and Yang, K. (2001). On the (im)possibility of obfuscatingprograms. In CRYPTO ’01: Proceedings of the 21st Annual Interna-tional Cryptology Conference on Advances in Cryptology, pages 1–18,London, UK. Springer-Verlag.

Bardin, S. and Herrmann, P. (2008). Structural testing of executables.In Proceedings of the 2008 International Conference on Software Testing,Verification, and Validation, pages 22–31, Washington, DC, USA. IEEEComputer Society.

Bardin, S. and Herrmann, P. (2011). Osmose: automatic structuraltesting of executables. Softw. Test. Verif. Reliab., 21:29–54.

Billet, O., Gilbert, H., and Ech-Chatbi, C. (2005). Cryptanalysis of awhite box aes implementation. In Handschuh, H. and Hasan, M.,editors, Selected Areas in Cryptography, volume 3357 of Lecture Notesin Computer Science, pages 227–240. Springer Berlin / Heidelberg.

Brosch, F., Buhnova, B., Koziolek, H., and Reussner, R. (2011). Re-liability prediction for fault-tolerant software architectures. In Pro-ceedings of the joint ACM SIGSOFT conference – QoSA and ACM SIG-SOFT symposium – ISARCS on Quality of software architectures – QoSAand architecting critical systems – ISARCS, QoSA-ISARCS ’11, pages75–84, New York, NY, USA. ACM.

BSA (2010). Seventh annual bsa/idc global software piracy study.

BSA (2012). Shadow market, 2011 bsa global software piracy study.

Cai, H., Shao, Z., and Vaynberg, A. (2007). Certified self-modifyingcode. In PLDI ’07: Proceedings of the 2007 ACM SIGPLAN conferen-ce on Programming language design and implementation, pages 66–77,New York, NY, USA. ACM.

bibliografía 193

Cappaert, J., Preneel, B., Anckaert, B., Madou, M., and De Bosschere,K. (2008). Towards tamper resistant code encryption: Practice andexperience. In Chen, L., Mu, Y., and Susilo, W., editors, Informa-tion Security Practice and Experience, volume 4991 of Lecture Notes inComputer Science, pages 86–100. Springer Berlin / Heidelberg.

Chang, H. and Atallah, M. (2002). Protecting software code by guards.In Sander, T., editor, Security and Privacy in Digital Rights Manage-ment, volume 2320 of Lecture Notes in Computer Science, pages 125–141. Springer Berlin / Heidelberg.

Chang, K. and Shin, K. G. (2008). Distributed authentication of pro-gram integrity verification in wireless sensor networks. ACM Trans.Inf. Syst. Secur., 11:14:1–14:35.

Chatzikokolakis, K., Palamidessi, C., and Panangaden, P. (2008).Anonymity protocols as noisy channels. Journal Information andComputation, 206:378–401.

Chen, H.-Y., Hou, T.-W., and Lin, C.-L. (2007). Tamper-proofing basispath by using oblivious hashing on java. SIGPLAN Not., 42(2):9–16.

Chen, Y., Venkatesan, R., Cary, M., Pang, R., Sinha, S., and Jakubows-ki, M. H. (2003). Oblivious hashing: A stealthy software integrityverification primitive. In IH ’02: Revised Papers from the 5th Interna-tional Workshop on Information Hiding, pages 400–414, London, UK.Springer-Verlag.

Chhabra, S., Rogers, B., Solihin, Y., and Prvulovic, M. (2009). Makingsecure processors os- and performance-friendly. ACM Trans. Archit.Code Optim., 5(4):1–35.

Chou, H.-Z., Chang, K.-H., and Kuo, S.-Y. (2011). Facilitating unrea-chable code diagnosis and debugging. In Proceedings of the 16th Asiaand South Pacific Design Automation Conference, ASPDAC ’11, pages485–490, Piscataway, NJ, USA. IEEE Press.

Chow, S., Eisen, P., Johnson, H., and van Oorschot, P. (2003). A white-box des implementation for drm applications. In Digital Rights Ma-nagement, volume 2696 of Lecture Notes in Computer Science, pages1–15. Springer Berlin / Heidelberg.

194 bibliografía

Clark, D., Hunt, S., and Malacaria, P. (2007). A static analysis for quan-tifying information flow in a simple imperative language. Journalof Computer Security, 15(3):321–371.

Collberg, C. and Nagra, J. (2009). Surreptitious Software: Obfuscation,Watermarking, and Tamperproofing for Software Protection. Addison-Wesley Professional.

Collberg, C. S. and Thomborson, C. (2002). Watermarking, tamper-proofing, and obfuscation - tools for software protection. SoftwareEngineering, IEEE Transactions on, 28(8):735–746.

Czitrom, V. (1999). One-factor-at-a-time versus designed experiments.The American Statistician, 53(2):126–131.

Dalla Preda, M. and Giacobazzi, R. (2009). Semantics-based code ob-fuscation by abstract interpretation. Journal of Computer Security,17(6):855–908.

Das, S. K. and Ho, J.-W. (2011). A synopsis on node compromisedetection in wireless sensor networks using sequential analysis (in-vited review article). Comput. Commun., 34:2003–2012.

Dedic, N., Jakubowski, M., and Venkatesan, R. (2007). A graph ga-me model for software tamper protection. In Furon, T., Cayre, F.,DoÃ«rr, G., and Bas, P., editors, Information Hiding, volume 4567

of Lecture Notes in Computer Science, pages 80–95. Springer Berlin /Heidelberg.

Eilam, E. (2005). Reversing: Secrets of Reverse Engineering. Wiley.

Garey, M. R. and Johnson, S. S. (1979). Computers and Intractability: Aguide to the theory of NP-Completeness. W. H. Freeman and Company.

Ghosh, S., Hiser, J. D., and Davidson, J. W. (2010). A secure and ro-bust approach to software tamper resistance. In Information Hiding,number 6387 in Lecture Notes in Computer Science, pages 33–47.Springer Berlin Heidelberg.

Giffin, J. T., Christodorescu, M., and Kruger, L. (2005). Strengthe-ning software self-checksumming via self-modifying code. In Pro-ceedings of the 21st Annual Computer Security Applications Conference.

bibliografía 195

Gilchrist, W. (2000). Statistical Modelling with Quantile Functions. Chap-man and Hall/CRC, 1 edition.

Goldwasser, S. and Kalai, Y. T. (2005). On the impossibility of ob-fuscation with auxiliary input. In Proc. 46th Annual IEEE Symp.Foundations of Computer Science FOCS 2005, pages 553–562.

Goubin, L., Masereel, J.-M., and Quisquater, M. (2007). Cryptanalysisof white box des implementations. In SAC’07: Proceedings of the14th international conference on Selected areas in cryptography, pages278–295, Berlin, Heidelberg. Springer-Verlag.

Gromov, M. L., Evtushenko, N. V., and Kolomeets, A. V. (2008). Onthe synthesis of adaptive tests for nondeterministic finite state ma-chines. Program. Comput. Softw., 34:322–329.

Guderlei, R., Mayer, J., Schneckenburger, C., and Fleischer, F. (2007).Testing randomized software by means of statistical hypothesistests. In Fourth international workshop on Software quality assuran-ce: in conjunction with the 6th ESEC/FSE joint meeting, SOQUA ’07,pages 46–54, New York, NY, USA. ACM.

Hamadou, S., Sassone, V., and Palamidessi, C. (2010). Reconcilingbelief and vulnerability in information flow. In Proc. IEEE Symp.Security and Privacy (SP), pages 79–92.

Hashmi, S. and Brooke, J. (2008). Towards time limited secure agentexecution on malicious host: A concept paper. Network and ParallelComputing Workshops, IFIP International Conference on, 0:155–162.

Hashmi, S. and Brooke, J. (2009). A software based approach for trus-ted agent execution on malicious host. In Proceedings of the 2009International Conference on Computational Science and Engineering -Volume 02, CSE ’09, pages 837–846, Washington, DC, USA. IEEEComputer Society.

Henning, J. (2000). Spec cpu2000: measuring cpu performance in thenew millennium. Computer, 33(7):28 –35.

Horne, B., Matheson, L., Sheehan, C., and Tarjan, R. (2002). Dynamicself-checking techniques for improved tamper resistance. In Sander,

196 bibliografía

T., editor, Security and Privacy in Digital Rights Management, volume2320 of Lecture Notes in Computer Science, pages 77–124. SpringerBerlin / Heidelberg.

Jacob, M., Jakubowski, M. H., and Venkatesan, R. (2007). Towardsintegral binary execution: implementing oblivious hashing usingoverlapped instruction encodings. In MM&Sec ’07: Proceedingsof the 9th workshop on Multimedia & security, pages 129–140, NewYork, NY, USA. ACM.

Jakubowski, M., Naldurg, P., Patankar, V., and Venkatesan, R. (2007).Software integrity checking expressions (ices) for robust tamper de-tection. In IH’07: Proceedings of the 9th international conference on In-formation hiding, pages 96–111, Berlin, Heidelberg. Springer-Verlag.

Jakubowski, M. H., Saw, C. W., and Venkatesan, R. (2009). Tamper-tolerant software: Modeling and implementation. In IWSEC ’09:Proceedings of the 4th International Workshop on Security, pages 125–139, Berlin, Heidelberg. Springer-Verlag.

Jin, H. and Lotspiech, J. (2003a). Forensic analysis for tamper resistantsoftware. In Proc. 14th Int. Symp. Software Reliability EngineeringISSRE 2003, pages 133–142.

Jin, H. and Lotspiech, J. (2003b). Proactive software tampering detec-tion. In Information Security, volume 2851 of Lecture Notes in Compu-ter Science, pages 352–365. Springer Berlin / Heidelberg.

Jin, H. and Myles, G. (2007). A technique for self-certifying tamperresistant software. In QoP ’07: Proceedings of the 2007 ACM workshopon Quality of protection, pages 12–14, New York, NY, USA. ACM.

Jin, H., Myles, G., and Lotspiech, J. (2005). Towards better softwaretamper resistance. In Zhou, J., Lopez, J., Deng, R. H., and Bao, F.,editors, Information Security, volume 3650 of Lecture Notes in Compu-ter Science, pages 417–430. Springer Berlin / Heidelberg.

Jin, H., Myles, G., and Lotspiech, J. (2007). Key evolution-based tam-per resistance: a subgroup extension. In ASIACCS ’07: Proceedings ofthe 2nd ACM symposium on Information, computer and communicationssecurity, pages 321–328, New York, NY, USA. ACM.

bibliografía 197

Jürgenson, A. and Willemson, J. (2008). Computing exact outcomesof multi-parameter attack trees. In Proceedings of the OTM 2008Confederated International Conferences, CoopIS, DOA, GADA, IS, andODBASE 2008. Part II on On the Move to Meaningful Internet Systems,OTM ’08, pages 1036–1051, Berlin, Heidelberg. Springer-Verlag.

Jürgenson, A. and Willemson, J. (2010). Serial model for attack treecomputations. In Proceedings of the 12th international conference onInformation security and cryptology, ICISC’09, pages 118–128, Berlin,Heidelberg. Springer-Verlag.

Kim, S. S., Lee, D. G., and Park, J. H. (2012). Efficient scheme ofverifying integrity of application binaries in embedded operatingsystems. J. Supercomput., 59(2):676–692.

Köpf, B. and Basin, D. (2007). An information-theoretic model foradaptive side-channel attacks. In CCS ’07: Proceedings of the 14thACM conference on Computer and communications security, pages 286–296, New York, NY, USA. ACM.

Kordy, B., Mauw, S., Melissen, M., and Schweitzer, P. (2010). Attack-defense trees and two-player binary zero-sum extensive form ga-mes are equivalent. In Proceedings of the First international conferenceon Decision and game theory for security, GameSec’10, pages 245–256,Berlin, Heidelberg. Springer-Verlag.

Kordy, B., Mauw, S., Radomirovic, S., and Schweitzer, P. (2011). Foun-dations of attack-defense trees. In Proceedings of the 7th Internationalconference on Formal aspects of security and trust, FAST’10, pages 80–95, Berlin, Heidelberg. Springer-Verlag.

Kotler, P. and Armstrong, G. (2011). Principles of Marketing, chapterNew Product Development and Product Life-Cycle Strategies, pa-ges 258–287. Pearson Education, 14 edition.

Kushwaha, D. S. and Misra, A. K. (2008). Software test effort estima-tion. ACM SIGSOFT Software Engineering Notes, 33(3):6:1–6:5.

Lakhotia, K., McMinn, P., and Harman, M. (2009). Automated testdata generation for coverage:haven’t we solved this problem yet?

198 bibliografía

Lakhotia, K., McMinn, P., and Harman, M. (2010). An empirical inves-tigation into branch coverage for c programs using cute and austin.Journal of Systems and Software.

Lee, J., Kim, H., and Yoon, H. (2005). Tamper resistant software byintegrity-based encryption. In Liew, K.-M., Shen, H., See, S., andCai, W., editors, Parallel and Distributed Computing: Applications andTechnologies, volume 3320 of Lecture Notes in Computer Science, pages75–89. Springer Berlin / Heidelberg.

Lenth, R. V. (1989). Quick and easy analysis of unreplicated factorials.Technometrics, 31(4):469–473.

Li, D., Hu, Y., Hu, X., and Ling, H. (2009a). Self-checking tamper-proofing based on software behavior model. In Proc. Fourth Int.Conf. Frontier of Computer Science and Technology FCST ’09, pages639–643.

Li, G., Lu, K., Zhang, Y., Lu, X., and Zhang, W. (2009b). Mixing con-crete and symbolic execution to improve the performance of dyna-mic test generation. In Proceedings of the 3rd international conferenceon New technologies, mobility and security, NTMS’09, pages 223–227,Piscataway, NJ, USA. IEEE Press.

Liem, C., Gu, Y. X., and Johnson, H. (2008). A compiler-based in-frastructure for software-protection. In Proceedings of the third ACMSIGPLAN workshop on Programming languages and analysis for secu-rity, PLAS ’08, pages 33–44, New York, NY, USA. ACM.

Limayem, M., Khalifa, M., and Chin, W. (2004). Factors motivatingsoftware piracy: a longitudinal study. Engineering Management,IEEE Transactions on, 51(4):414 – 425.

Lin, Q., Xia, M., Yu, M., Yud, P., Zhu, M., Gao, S., Qi, Z., Chen, K., andGuan, H. (2011). Spad: software protection through anti-debuggingusing hardware virtualization. In Proceedings of the 2011 ACM Sym-posium on Applied Computing, SAC ’11, pages 623–624, New York,NY, USA. ACM.

Linda, O. and Manic, M. (2011). Interval type-2 fuzzy voter designfor fault tolerant systems. Inf. Sci., 181:2933–2950.

bibliografía 199

Madou, M., Anckaert, B., De Sutter, B., and De Bosschere, K. (2005).Hybrid static-dynamic attacks against software protection mecha-nisms. In DRM ’05: Proceedings of the 5th ACM workshop on Digitalrights management, pages 75–82, New York, NY, USA. ACM.

Maia, C. L. B., do Carmo, R. A. F., de Freitas, F. G., de Campos, G.A. L., and de Souza, J. T. (2010). Automated test case prioritizationwith reactive grasp. Adv. Soft. Eng., 2010:2:1–2:13.

Majumdar, R. and Sen, K. (2007). Hybrid concolic testing. In Procee-dings of the 29th international conference on Software Engineering, ICSE’07, pages 416–426, Washington, DC, USA. IEEE Computer Society.

Malacaria, P. (2007). Assessing security threats of looping constructs.In POPL ’07: Proceedings of the 34th annual ACM SIGPLAN-SIGACTsymposium on Principles of programming languages, pages 225–235,New York, NY, USA. ACM.

Malacaria, P. and Chen, H. (2008). Lagrange multipliers and maxi-mum information leakage in different observational models. InPLAS ’08: Proceedings of the third ACM SIGPLAN workshop on Pro-gramming languages and analysis for security, pages 135–146, NewYork, NY, USA. ACM.

Malacaria, P. and Heusser, J. (2010). Information theory and security:Quantitative information flow. In Aldini, A., Bernardo, M., Di Pie-rro, A., and Wiklicky, H., editors, Formal Methods for QuantitativeAspects of Programming Languages, volume 6154 of Lecture Notes inComputer Science, pages 87–134. Springer Berlin / Heidelberg.

Mao, S. and Wolf, T. (2010). Hardware support for secure processingin embedded systems. IEEE Trans. Comput., 59(6):847–854.

Mason, S. (2005). Trusting your computer to be trusted. ComputerFraud & Security, 2005(1):7 – 11.

Mavrogiannopoulos, N., Kisserli, N., and Preneel, B. (2011). A taxo-nomy of self-modifying code for obfuscation. Computers & Security,30(8):679 – 691.

200 bibliografía

McCamant, S. and Ernst, M. D. (2008). Quantitative information flowas network flow capacity. In PLDI ’08: Proceedings of the 2008 ACMSIGPLAN conference on Programming language design and implementa-tion, pages 193–205, New York, NY, USA. ACM.

McMinn, P. (2004). Search-based software test data generation: Asurvey. Software Testing, Verification and Reliability, 14(2):105–156.

MeiHong, L. and JiQiang, L. (2009). Usb key-based approach forsoftware protection. In Industrial Mechatronics and Automation, 2009.ICIMA 2009. International Conference on, pages 151 –153.

Menezes, A. J., Vanstone, S. A., and Oorschot, P. C. V. (1996). Handbookof Applied Cryptography. CRC Press, Inc, Boca Raton, FL, USA.

Michiels, W. (2010). Opportunities in white-box cryptography. IEEESecurity & Privacy, 8(1):64–67.

Montgomery, D. C. (2009). Design and Analysis of Experiments. Wiley,7 edition.

Nachmanson, L., Veanes, M., Schulte, W., Tillmann, N., and Gries-kamp, W. (2004). Optimal strategies for testing nondeterministicsystems. SIGSOFT Softw. Eng. Notes, 29:55–64.

Nagra, J., Thomborson, C., and Collberg, C. (2002). A functional ta-xonomy for software watermarking. In ACSC ’02: Proceedings of thetwenty-fifth Australasian conference on Computer science, pages 177–186, Darlinghurst, Australia, Australia. Australian Computer So-ciety, Inc.

Newsome, J., McCamant, S., and Song, D. (2009). Measuring channelcapacity to distinguish undue influence. In PLAS ’09: Proceedings ofthe ACM SIGPLAN Fourth Workshop on Programming Languages andAnalysis for Security, pages 73–85, New York, NY, USA. ACM.

Oishi, K. and Matsumoto, T. (2011). Self destructive tamper responsefor software protection. In Proceedings of the 6th ACM Symposiumon Information, Computer and Communications Security, ASIACCS ’11,pages 490–496, New York, NY, USA. ACM.

bibliografía 201

Park, T. and Shin, K. G. (2005). Soft tamper-proofing via programintegrity verification in wireless sensor networks. IEEE Transactionson Mobile Computing, 4:297–309.

Piazzalunga, U., Salvaneschi, P., Balducci, F., Jacomuzzi, P., and Mo-roncelli, C. (2007). Security strength measurement for dongle-protected software. IEEE Security and Privacy, 5:32–40.

Price, S. M. (2008). Host-based security challenges and controls: Asurvey of contemporary research. Inf. Sec. J.: A Global Perspective,17:170–178.

Robling Denning, D. E. (1982). Cryptography and data security.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

Rogers, A., Milenkovic, M., and Milenkovic, A. (2007). A low over-head hardware technique for software integrity and confidentiality.In Proc. 25th Int. Conf. Computer Design ICCD 2007, pages 113–120.

Saini, V., Duan, Q., and Paruchuri, V. (2008). Threat modeling usingattack trees. J. Comput. Sci. Coll., 23:124–131.

Salvaneschi, P. and Piazzalunga, U. (2008). Engineering models andsoftware quality models: an example and a discussion. In Procee-dings of the 2008 international workshop on Models in software enginee-ring, MiSE ’08, pages 39–44, New York, NY, USA. ACM.

Schneier, B. (1999). Attack trees: Modeling security threats. Dr. Dobb’sjournal, 24(12):21–29.

Schrittwieser, S. and Katzenbeisser, S. (2011). Code obfuscationagainst static and dynamic reverse engineering. In Proceedings ofthe 13th international conference on Information hiding, IH’11, pages270–284, Berlin, Heidelberg. Springer-Verlag.

Sen, K. (2007). Concolic testing. In Proceedings of the twenty-secondIEEE/ACM international conference on Automated software engineering,ASE ’07, pages 571–572, New York, NY, USA. ACM.

Sharma, A. and Kushwaha, D. S. (2012). Applying requirement basedcomplexity for the estimation of software development and testingeffort. ACM SIGSOFT Software Engineering Notes, 37(1):1–11.

202 bibliografía

Smith, G. (2009). On the foundations of quantitative informationflow. In Alfaro, L., editor, Foundations of Software Science and Compu-tational Structures, volume 5504 of Lecture Notes in Computer Science,chapter 21, pages 288–302. Springer Berlin / Heidelberg.

Stamp, M. (2011). Information Security: Principles and Practice. Wiley,2nd edition.

Tan, G., Chen, Y., and Jakubowski, M. H. (2007). Delayed and con-trolled failures in tamper-resistant software. In IH’06: Proceedings ofthe 8th international conference on Information hiding, pages 216–231,Berlin, Heidelberg. Springer-Verlag.

Thomas M. Cover, J. A. T. (2006). Elements of Information Theory. Wiley-Interscience, 2nd edition edition.

Tsang, H.-C., Lee, M.-C., and Pun, C.-M. (2011). A robust anti-tamperprotection scheme. In 2011 Sixth International Conference on Availabi-lity, Reliability and Security (ARES), pages 109 –118.

Tsaur, W.-J. (2012). Secure communication for electronic business ap-plications in mobile agent networks. Expert Syst. Appl., 39:1046–1054.

Vain, J., Raiend, K., Kull, A., and Ernits, J. P. (2007). Synthesis oftest purpose directed reactive planning tester for nondeterministicsystems. In Proceedings of the twenty-second IEEE/ACM internationalconference on Automated software engineering, ASE ’07, pages 363–372,New York, NY, USA. ACM.

van Oorschot, P. C., Somayaji, A., and Wurster, G. (2005). Hardware-assisted circumvention of self-hashing software tamper resistance.IEEE Transactions on Dependable and Secure Computing, 2(2):82–92.

Verendel, V. (2009). Quantified security is a weak hypothesis: a criticalsurvey of results and assumptions. In NSPW ’09: Proceedings of the2009 workshop on New security paradigms workshop, pages 37–50, NewYork, NY, USA. ACM.

von Oheimb, D. (2004). Information flow control revisited: Nonin-fluence = noninterference + nonleakage. In Computer Security - ESO-

bibliografía 203

RICS 2004, volume 3193 of Lecture Notes in Computer Science, pages225–243. Springer Berlin Heidelberg.

Whitley, J. N., Phan, R. C. W., Wang, J., and Parish, D. J. (2011). Techni-cal communication: Attribution of attack trees. Comput. Electr. Eng.,37:624–628.

Wurster, G. and van Oorschot, P. C. (2008). The developer is theenemy. In NSPW ’08: Proceedings of the 2008 workshop on New securityparadigms, pages 89–97, New York, NY, USA. ACM.

Wurster, G., van Oorschot, P. C., and Somayaji, A. (2005). A genericattack on checksumming-based software tamper resistance. In Proc.IEEE Symp. Security and Privacy, pages 127–138.

Wyseur, B. (2010). Re-trust: Trustworthy execution of sw on remoteuntrusted platforms. In Pohlmann, N., Reimer, H., and Schneider,W., editors, ISSE 2009 Securing Electronic Business Processes, pages328–338. Vieweg+Teubner.

Wyseur, B., Michiels, W., Gorissen, P., and Preneel, B. (2007). Crypta-nalysis of white-box des implementations with arbitrary externalencodings. In SAC’07: Proceedings of the 14th international conferenceon Selected areas in cryptography, pages 264–277, Berlin, Heidelberg.Springer-Verlag.

Yasuoka, H. and Terauchi, T. (2010). Quantitative information flow -verification hardness and possibilities. In Proc. 23rd IEEE ComputerSecurity Foundations Symp. (CSF), pages 15–27.

Yi, T., Zong, A., Yu, M., Gao, S., Lin, Q., Yu, P., Ren, Z., and Qi, Z.(2009). Anti-debugging framework based on hardware virtualiza-tion technology. In Proceedings of the 2009 International Conference onResearch Challenges in Computer Science, ICRCCS ’09, pages 218–220,Washington, DC, USA. IEEE Computer Society.

Yoo, S. and Harman, M. (2007). Pareto efficient multi-objective testcase selection. In Proceedings of the 2007 international symposium onSoftware testing and analysis, ISSTA ’07, pages 140–150, New York,NY, USA. ACM.

204 bibliografía

Yoo, S. and Harman, M. (2010a). Regression testing minimization,selection and prioritization: a survey. Software Testing, Verificationand Reliability, pages n/a–n/a.

Yoo, S. and Harman, M. (2010b). Using hybrid algorithm for pare-to efficient multi-objective test suite minimisation. J. Syst. Softw.,83:689–701.

yuan Zheng, S. and Liu, J. (2010). An usb key_based approach forsoftware tamper resistance. In Advanced Computer Theory and En-gineering (ICACTE), 2010 3rd International Conference on, volume 6,pages 506–509.

Zhu, W., Thomborson, C., and Wang, F.-Y. (2005). A survey of soft-ware watermarking. In Kantor, P., Muresan, G., Roberts, F., Zeng,D. D., Wang, F.-Y., Chen, H., and Merkle, R. C., editors, Intelligenceand Security Informatics, volume 3495 of Lecture Notes in ComputerScience, pages 454–458. Springer Berlin / Heidelberg.

colofón

This document was typeset using the typographical look-and-feelclassicthesis developed by André Miede. The style was inspiredby Robert Bringhurst’s seminal book on typography “The Elements ofTypographic Style”. classicthesis is available for both LATEX and LYX:

http://code.google.com/p/classicthesis/

http://code.google.com/p/classicthesis/

Documents

Modelo no determinista para la auto-verificación de ...rua.ua.es/dspace/bitstream/10045/28518/1/tesis_yulier.pdf · Quiero agradecer profunda y sinceramente a mis directores de tesis,