WSI

II WORKSHOP DE SEGURIDAD INFORMÁTICA - WSI -

XIX Congreso Argentino de Ciencias de la Computación - CACIC 2013 : Octubre 2013, Mar del Plata, Argentina : organizadores : Red de Universidades con Carreras en Informática RedUNCI, Universidad CAECE / Armando De Giusti ... [et.al.] ; compilado por Jorge Finochietto ; ilustrado por María Florencia Scolari. - 1a ed. - Mar del Plata : Fundación de Altos Estudios en Ciencias Exactas, 2013.

E-Book.

ISBN 978-987-23963-1-2 1. Ciencias de la Computación. I. De Giusti, Armando II. Finochietto, Jorge, comp. III. Scolari, María Florencia, ilus.

CDD 005.3 Fecha de catalogación: 03/10/2013

AUTORIDADES DE LA REDUNCI Coordinador Titular De Giusti Armando (UNLP) 2012-2014 Coordinador Alterno Simari Guillermo (UNS) 2012-2014 Junta Directiva Feierherd Guillermo (UNTF) 2012-2014 Padovani Hugo (UM) 2012-2014 Estayno Marcelo (UNLZ) 2012-2014 Esquivel Susana (UNSL) 2012-2014 Alfonso Hugo (UNLaPampa) 2012-2013 Acosta Nelson (UNCPBA) 2012-2013 Finochietto, Jorge (UCAECE) 2012-2013 Kuna Horacio (UNMisiones) 2012-2013 Secretarias Secretaría Administrativa: Ardenghi Jorge (UNS) Secretaría Académica: Spositto Osvaldo (UNLaMatanza) Secretaría de Congresos, Publicaciones y Difusión: Pesado Patricia (UNLP) Secretaría de Asuntos Reglamentarios: Bursztyn Andrés (UTN)

AUTORIDADES DE LA UNIVERSIDAD CAECE Rector Dr. Edgardo Bosch Vicerrector Académico Dr. Carlos A. Lac Prugent Vicerrector de Gestión y Desarrollo Educativo Dr. Leonardo Gargiulo Vicerrector de Gestión Administrativa Mg. Fernando del Campo Vicerrectora de la Subsede Mar del Plata: Mg. Lic. María Alejandra Cormons Secretaria Académica: Lic. Mariana A. Ortega Secretario Académico de la Subsede Mar del Plata Esp. Lic. Jorge Finochietto Director de Gestión Institucional de la Subsede Mar del Plata Esp. Lic. Gustavo Bacigalupo Coordinador de Carreras de Lic. e Ing. en Sistemas Esp. Lic. Jorge Finochietto

COMITÉ ORGANIZADOR LOCAL Presidente Esp. Lic. Jorge Finochietto Miembros Esp. Lic. Gustavo Bacigalupo Mg. Lic. Lucia Malbernat Lic. Analía Varela Lic. Florencia Scolari C.C. María Isabel Meijome CP Mayra Fullana Lic. Cecilia Pellerini Lic. Juan Pablo Vives Lic. Luciano Wehrli

Escuela Internacional de Informática (EII) Directora Dra. Alicia Mon Coordinación CC. María Isabel Meijome

comité académico Universidad

Representante

Universidad de Buenos Aires

Echeverria, Adriana (Ingeniería) – Fernández

Universidad Nacional de La Plata

Slezak, Diego (Cs. Exactas)

Universidad Nacional del Sur

De Giusti, Armando

Universidad Nacional de San Luis

Simari, Guillermo

Universidad Nacional del Centro de la

Esquivel, Susana

Provincia de Buenos Aires

Acosta, Nelson

Universidad Nacional del Comahue

Vaucheret, Claudio

Universidad Nacional de La Matanza

Spositto, Osvaldo

Universidad Nacional de La Pampa

Alfonso, Hugo

Universidad Nacional Lomas de Zamora

Estayno, Marcelo

Universidad Nacional de Tierra del Fuego

Feierherd, Guillermo

Universidad Nacional de Salta

Gil, Gustavo

Universidad Nacional Patagonia Austral

Márquez, María Eugenia

Universidad Tecnológica Nacional

Leone, Horacio

Universidad Nacional de San Juan

Otazú, Alejandra

Universidad Autónoma de Entre Ríos

Aranguren, Silvia

Universidad Nacional Patagonia San Juan

Buckle, Carlos

Bosco Universidad Nacional de Entre Ríos

Tugnarelli, Mónica

Universidad Nacional del Nordeste

Dapozo, Gladys

Universidad Nacional de Rosario

Kantor, Raúl

Universidad Nacional de Misiones

Kuna, Horacio

Universidad Nacional del Noroeste de la

Russo, Claudia

Provincia de Buenos Aires Universidad Nacional de Chilecito

Carmona, Fernanda

Universidad Nacional de Lanús

García Martínez, Ramón

comité académico Universidad

Representante

Universidad Nacional de Santiago del Estero

Durán, Elena

Escuela Superior del Ejército

Castro Lechstaler Antonio

Universidad Nacional del Litoral

Loyarte, Horacio

Universidad Nacional de Rio Cuarto

Arroyo, Marcelo

Universidad Nacional de Córdoba

Brandán Briones, Laura

Universidad Nacional de Jujuy

Paganini, José

Universidad Nacional de Río Negro

Vivas, Luis

Universidad Nacional de Villa María

Prato, Laura

Universidad Nacional de Luján

Scucimarri, Jorge

Universidad Nacional de Catamarca

Barrera, María Alejandra

Universidad Nacional de La Rioja

Nadal, Claudio

Universidad Nacional de Tres de Febrero

Cataldi, Zulma

Universidad Nacional de Tucumán

Luccioni, Griselda

Universidad Nacional Arturo Jauretche

Morales, Martín

Universidad Nacional del Chaco Austral

Zachman, Patricia

Universidad de Morón

Padovani, Hugo René

Universidad Abierta Interamericana

De Vincenzi, Marcelo

Universidad de Belgrano

Guerci, Alberto

Universidad Kennedy

Foti, Antonio

Universidad Adventista del Plata

Bournissen, Juan

Universidad CAECE

Finochietto, Jorge

Universidad de Palermo

Ditada, Esteban

Universidad Católica Argentina - Rosario

Grieco, Sebastián

Universidad del Salvador

Zanitti, Marcelo

Universidad del Aconcagua

Gimenez, Rosana

Universidad Gastón Dachary

Belloni, Edgardo

Universidad del CEMA

Guglianone, Ariadna

Universidad Austral

Robiolo, Gabriela

comité científico Coordinación Armando De Giusti (UNLP) - Guillermo Simari (UNS) Abásolo, María José (Argentina) Acosta, Nelson (Argentina) Aguirre Jorge Ramió (España) Alfonso, Hugo (Argentina) Ardenghi, Jorge (Argentina) Baldasarri Sandra (España) Balladini, Javier (Argentina) Bertone, Rodolfo (Argentina) Bría, Oscar (Argentina) Brisaboa, Nieves (España) Bursztyn, Andrés (Argentina) Cañas, Alberto (EE.UU) Casali, Ana (Argentina) Castro Lechtaller, Antonio (Argentina) Castro, Silvia (Argentina) Cechich, Alejandra (Argentina) Coello Coello, Carlos (México) Constantini, Roberto (Argentina) Dapozo, Gladys (Argentina) De Vicenzi, Marcelo (Argentina) Deco, Claudia (Argentina) Depetris, Beatriz (Argentina) Diaz, Javier (Argentina) Dix, Juerguen (Alemania) Doallo, Ramón (España) Docampo, Domingo Echaiz, Javier (Argentina) Esquivel, Susana (Argentina) Estayno, Marcelo (Argentina) Estevez, Elsa (Naciones Unidas) Falappa, Marcelo (Argentina) Feierherd, Guillermo (Argentina) Ferreti, Edgardo (Argentina) Fillottrani, Pablo (Argentina) Fleischman, William (EEUU) García Garino, Carlos (Argentina) García Villalba, Javier (España) Género, Marcela (España) Giacomantone, Javier (Argentina) Gómez, Sergio (Argentina) Guerrero, Roberto (Argentina) Henning Gabriela (Argentina)

Janowski, Tomasz (Naciones Unidas) Kantor, Raul (Argentina) Kuna, Horacio (Argentina) Lanzarini, Laura (Argentina) Leguizamón, Guillermo (Argentina) Loui, Ronald Prescott (EEUU) Luque, Emilio (España) Madoz, Cristina (Argentina) Malbran, Maria (Argentina) Malverti, Alejandra (Argentina) Manresa-Yee, Cristina (España) Marín, Mauricio (Chile) Motz, Regina (Uruguay) Naiouf, Marcelo (Argentina) Navarro Martín, Antonio (España) Olivas Varela, José Ángel (España) Orozco Javier (Argentina) Padovani, Hugo (Argentina) Pardo, Álvaro (Uruguay) Pesado, Patricia (Argentina) Piattini, Mario (España) Piccoli, María Fabiana (Argentina) Printista, Marcela (Argentina) Ramón, Hugo (Argentina) Reyes, Nora (Argentina) Riesco, Daniel (Argentina) Rodríguez, Ricardo (Argentina) Roig Vila, Rosabel (España) Rossi, Gustavo (Argentina) Rosso, Paolo (España) Rueda, Sonia (Argentina) Sanz, Cecilia (Argentina) Spositto, Osvaldo (Argentina) Steinmetz, Ralf (Alemania) Suppi, Remo (España) Tarouco, Liane (Brasil) Tirado, Francisco (España) Vendrell, Eduardo (España) Vénere, Marcelo (Argentina) Villagarcia Wanza, Horacio (Arg.) Zamarro, José Miguel (España)

II Workshop de Seguridad Informática - WSI -

ID

Trabajo

Autores

5606

Improving versatility in keystroke dynamic systems

Enrique P. Calot (UBA), Juan Manuel Rodríguez (UBA), Jorge Salvador Ierache

5713

Gestión Integral de Seguridad de Infraestructuras críticas para las organizaciones locales alineadas a las Normas IRAM ISO IEC 27.001 y 27002.

Mirta Elizabeth Navarro (UNSJ), María del Carmen Becerra (UNSJ)

5753

Model Design for a Reduced Variant of a Trivium Type Stream Cipher

Antonio Castro Lechtaler (IESE), Marcelo Cipriano (IESE), Edith García (IESE), Julio Liporace (IESE), Ariel Maiorano (IESE), Eduardo Malvacio (IESE)

5801

Usability Support Security Patterns

Susana Romaniz (UTN-FRSF), Marta Castellaro (UTN-FRSF), Juan Ramos (UTNFRSF), Ignacio Ramos (UTN-FRSF)

5873

Analizador de Intents en Android

Joaquín Erario (UNRC), Christian Rovera (UNRC), Francisco Bavera (UNRC)

Improving versatility in keystroke dynamic systems Enrique Calot, Juan Manuel Rodriguez, and Jorge Salvador Ierache?

Laboratorio de Sistemas de Informaci´ on Avanzados, Facultad de Ingenier´ıa, Universidad de Buenos Aires, Buenos Aires, Argentina {ecalot,jmrodri}@fi.uba.ar,jierache@yahoo.com.ar

Abstract. Keystroke dynamics is a biometric technique to identify users based on analyzing habitual rhythm patterns in the way they type. In order to implement this technique different algorithms to differentiate an impostor from an authorized user were suggested. One of the most precise method is the Mahalanobis distance which requires to calculate the covariance matrix with all that this implies: time processing and track each individual keystroke event. The hypothesis of this research was to find an algorithm as good as Mahalanobis which does not require track every single keystroke event and improve, where possible, the processing time. To make an experimental comparison between Mahalanobis distance and euclidean normalized, a distance which only requires calculate the variance, an already studied dataset was used. The results were that use normalized euclidean distance is almost as good as Mahalanobis distance even in some cases could work better.

Keywords: Keystroke Dynamics, Web based authentication, Mahalanobis distance, Biometrics, typing biometrics

1

Introduction

The variables that help make a handwritten signature a unique human identifier also provide a unique digital signature in the form of a stream of latency periods between keystrokes. The handwritten signature has a parallel on the keyboard.

The same neurophysiological factors that make a written signature unique are also exhibited in a user’s typing pattern[1].

Password typing is the most widely used identity verification method in World Wide Web based electronic commerce. Due to its simplicity, however, it is vulnerable to impostor attacks. Keystroke dynamics and password checking can be combined to result in a more secure verification system[2].

This authentication is fragile when there is a careless user and/or a weak password. Biometric characteristics are unique to each person and have advantages as they could not be stolen, lost, or forgotten[3, 4]. ?

This paper was done with Cloodie R&D Support

1465

2

Improving versatility in keystroke dynamic systems

The biometric technology employed in this paper is the typing biometrics, also known as keystroke dynamics. Typing biometrics is a process that analyzes the way a user types at a terminal by monitoring the keyboard inputs in attempt to identify users based on their habitual typing rhythm patterns[5, 4].

Even though WWW keystroke dynamic systems may run locally on the web browser, due to security measures it should be ran on the webserver layer. This paper discusses an approach to reduce data transmission size.

Using a know dataset[6] we designed an experiment to compare three methods to compute the keystroke dynamics of users and compare them with impostors.

Our hypothesis is that one of the most used and precise method –the Mahalanobis distance– is as successful as the second method –normalized euclidean distance–. Ignoring the success rates, there are some advantages that the normalized euclidean distance has over the Mahalanobis distance, so if the hypothesis is confirmed using this method should prove to be a more useful way to calculate keystroke dynamics.

Some advantages of the normalized euclidean distance ar the lesser transferred information, processing time and the bigger versatility when changing passwords.

2

Current implementations

There are different methods to compare keystrokes, all based on measuring the distances between two strokes, a negative result is found when both differ more than a threshold. One of the best methods is the Mahalanobis distance[2, 6].

Three methods are shown below, each method is a generalization of the previous one.

2.1

Euclidean distance

The time a user press a key or the time between one key and the other may result in a vector of events (Γ ). Each event represent a key hold time or the elapsed time between two keys. Since in the training phase an event may occur several times, the vector is a list of the expected values of every event time.

Calculating the euclidean distance between two vectors works as a comparison algorithm, with relatively high success rates[6]. d(Γ1 , Γ2 )2 = kΓ1 − Γ2 k2 =

N X (Γ1,i − Γ2,i )2

(1)

i=1

Where Γ1 is the vector of training event times and Γ2 is the vector of testing event times.

To optimize calculation timings the squared norm is actually used.

1466

Improving versatility in keystroke dynamic systems

2.2

3

Normalized euclidean distance

A disadvantage of the former method is that important information is ignored.

The variance of each event time should be taken into consideration, and that is exactly what the normalized euclidean distance does: adding the variance (s2i ) of each event time.

Using the inverted variance of the training set (Γ1 ) as a weight factor, the normalized euclidean distance is defined as d(Γ1 , Γ2 )2 =

N X (Γ1,i − Γ2,i )2 i=1

s2i

(2)

where s2i is the variance of each element of Γ1 .

2.3

Mahalanobis distance

Again, the former method is skipping information, this time is the covariance between events.

Mahalanobis distance is defined as d(Γ1 , Γ2 )2 = (Γ1 − Γ2 )T S −1 (Γ1 − Γ2 )

(3)

Where S −1 is the inverted covariance matrix corresponding to all events in the training set Γ1 [7].

3

Problems of Mahalanobis distance in keystroke dynamics

Translating each method to a kernel matrix it turns out that in equation 3 the matrix S is the identity in the euclidean distance, a diagonal with the variances in the normalized euclidean distance and the covariance matrix in the Mahalanobis distance.

3.1

Distance kernel matrix size

To generate the covariance matrix for the Mahalanobis distance all key-press events and their respective timings should be transmitted to the server while training –or at least the covariance matrix and the expected event timings–.

But to generate the diagonal matrix for the normalized euclidean method is it possible to send only three integer numbers per event or two floats.

2 Using the property V ar[X] = E[X 2 ] − E[X] possible to generate Pn the Pn it is 2 variance using only the sum of squares SS = i=0 Γ1,i , the sum S = i=0 Γ1,i S and the total n since E[X 2 ] = SS n and E[X] = n . All three numbers are natural and may be combined in an N3 vector which supports commutative addition properties. This method allows parallelized variance calculus[9].

1467

4

Improving versatility in keystroke dynamic systems Table 1. Different parameters to be sent to the server

Distance Method

Variables

Euclidean Normalized euclidean Mahalanobis

(S, n) ∈ N2×n or Γ = E[X] ∈ Rn (S, SS, n) ∈ N3×n n Γ = E[X] ∈ R and Cov[X] ∈ Rn×n

There are several ways to send the data depending on the algorithm to be used. Table 1 compares them.

For example, when 20 events are used, the covariance matrix has 20×20 = 400 values and the Γ = E[X] vector has 20 values. Normally a Rn×n matrix can be encoded with n2 numbers, but as Cov[a, b] = Cov[b, a], covariance matrix is numbers. Assuming a symmetric and therefore it can be encoded with n(n+1) 2 real number and an integer has the same size, the transmission would be of 20×21 + 20 = 230 numbers while the normalized euclidean only transmits 3 × 2 20 = 60 numbers. Generalizing, the data transmission of Mahalanobis distance is n(n+1) + n reals, that is O(n2 ), normalized euclidean is 3n integers, that is 2 O(n) and euclidean is 2n integers or n reals, that is also O(n).

3.2

One password algorithm

Another problem is that training is done with only one password. A new password should require the user to re-train all the covariance matrix with Mahalanobis.

Normalized euclidean distance may reuse the variances of the common keys between two different passwords while Mahalanobis distance may not.

3.3

Backspace eliminating digraphs

When the user trains it is possible that mistakes a character and use backspace to correct it, in this case one event will be missing. For example the word “train” has 5 characters so the events will be t.hold, t.up-r.down, r.hold, etc. The problem occurs when “te[backspace]rain” is typed, the event t.up-r.down was not recorded because there were two keys in the middle “e” and [backspace].

Having a variable number of events per key is a problem to calculate the covariance matrix, but allows to process backspaces in passwords (sacrificing the success rate due to lesser information available) and free text.

Table 2 shows an example of Mahalanobis method with three pairs of events and normalized euclidean with three and two times per event respectively.

3.4

Processing times

Calculating the covariance matrix and inverting it should take a considerable amount of time for the Mahalanobis method, the time here is expected to be

1468

Improving versatility in keystroke dynamic systems

5

Table 2. Example of how timing counts are dependent on the event in Mahalanobis distance Key Times Matrix S Inverse S −1

67 175 556 350 A.hold 90 99 97 − 2209 3 6 2209 , , 268 175 139 350 A.up-B.down 161 171 174 − 6 3 2209 2209 Mahalanobis 3 67

0 0 A.hold {90}, {99}, {97} 3 67 Normalized 1 0 50 0 50 A.up-B.down {161}, {171} euclidean Method

O(n2 ). Normalized euclidean should also take time to compute the variances, but this procedure is O(n). Inverting the matrix lacks of relevant costs due to the properties of the diagonal matrices. Euclidean distance should be the fastest algorithm because of its simplicity.

It is important to remark that due to parallelized calculation of the variance, part of the calculating time in training mode for the normalized euclidean distance may be done while reading the keyboard by the user machine.

The experiment also intends to measure algorithms processing time.

4

Experimental comparison

We use an already studied dataset for two main reasons, one is because it was collected in a controlled laboratory environment, the second reason is because 14 detection algorithms were tested using this dataset[6] and that give us a big framework to start our research. The data was collected from 50 different users along 8 days or sessions –totalizing 400 cases per user–, in each session the users typed always the same string: “.tie5Roanl� which represents a reasonable secure password. When any error in the sequence was detected, the subject had been prompted to retype the password. To make this a laptop was set up with an external keyboard to collect data and a Windows application was developed to prompt the subjects to type the password. The application displays it in a screen with a text-entry field. In order to advance to the next screen, the subject must type the 10 characters of the password correctly in sequence and then press Enter. The data set contains the hold time of each key, the time between two consecutive keys were pressed and the time since one key was released and the next was pressed. One of the three values depends linearly of the other two. Due to preconditions of covariance one value was dropped away leaving two values per key.

From the 400 cases per user, the first 200 cases were used to train the detection algorithm and the second 200 cases were used to validate it, also the first 5 cases of all the other users were taken to generate an impostor dataset in order to validate negative cases. This data set and schema was taken from Killourhy and Maxion[6].

We performed 19 tests, the first using two events (the first two values of the Γ vector) and increasing the number of events until the last one, using all twenty.

1469

6

Improving versatility in keystroke dynamic systems

We expected to have a best success rate in the last test because it counts with more information. We ran the three mentioned algorithms in each test.

Finally we calculated the area under the receiver operating characteristics (ROC) curve –a performance measure for machine learning algorithms commonly used in systems that learns by being shown labeled examples[8]–. This method, known as AUC, was chosen because it is a classifier performance evaluator independent of the decision threshold chosen on the keystroke distances.

5

Results

With the one key test case we obtained in one sample user Γ = [98.98, 166.905], where first value corresponds to the expected key-hold time and the second to the expected elapsed time until the next key was pressed. Both times are expressed in milliseconds.

−1

341.29 282.19 0.0031 −0.00016 −1 −1 SM ahalanobis = Cov[Γ ] = = 282.19 5464.9 −0.00016 0.0002

−1 SnormalizedEuclidean

341.29 0 = 0 5464.9

−1

−1 Seuclidean = Seuclidean =

0.0029 0 = 0 0.00018

10 01

Note that SM ahalanobis and SnormalizedEuclidean have the same diagonal values but this is not the case with their inverses.

Table 3. Experimental results

N Method

Total Errors

ROC

Zero-miss False-Alarm Time

2 Mahalanobis 2 Normalized euclidean 2 Euclidean

0.01887 80.43% 7461 of 12750 769 of 10200 1.356s 0.01899 80.17% 7451 of 12750 788 of 10200 1.300s 0.02240 70.61% 9030 of 12750 649 of 10200 0.872s

20 Mahalanobis 20 Normalized euclidean 20 Euclidean

0.00970 94.60% 5576 of 12750 464 of 10200 1.896s 0.00919 94.84% 5581 of 12750 428 of 10200 1.764s 0.01440 88.27% 6853 of 12750 844 of 10200 1.704s

Table 3 shows the results of the 3 methods with 2 and 20 timing events respectively. Each method shows the area under ROC curve in percentage among with zero-miss and false-alarm rates. It is also shown the total processing time

1470

Improving versatility in keystroke dynamic systems

7

of training, testing all the 12750 positive and 10200 negative sets and calculating the results.

In the last test –with 20 events–, normalized euclidean distance method performed even better than Mahalanobis.

As expected, our hypothesis that in the test with 20 timing events is better than the test with 2 was confirmed and that Mahalanobis and normalized euclidean distance are both superior than euclidean distance was confirmed too.

Processing is, as expected, bigger for Mahalanobis and decreasing for normalized euclidean and finally, the fastest method, euclidean distance.

100

95

ROC Area (%)

90

85

80

75

Mahalanobis Normalized Euclidean Euclidean

70 2

4

6

8

10

12

14

16

18

20

Number of events

Fig. 1. Distance methods compared in success versus amount of information

In Figure 1 it is possible to appreciate how similar are the normalized euclidean and Mahalanobis distances compared to the euclidean.

6

Conclusions

Normalized euclidean distance and Mahalanobis distance are almost the same in all ran tests. In the case of 20 events the results varied 0.24%. Normalized euclidean was faster than Mahalanobis distance for 132ms but slower than euclidean for only 60ms. Versatility in normalized euclidean is also an advantage, passwords may be changed and the already-trained keys be kept in the new training. Those results lead to the conclusion that normalized euclidean distance is strong enough to be used and its advantages in data sizes and versatility are considerably important to be chosen against Mahalanobis distance and its success rate suggests that it should be employed against euclidean distance.

1471

8

6.1

Improving versatility in keystroke dynamic systems

Future lines of research

We are exploring the way users may vary keystroke dynamics over the time.

Using variance parallelization principle[9] there is a way to “forget” the training, making it autoadaptive with this time-wise learning technique. We are also exploring new fields on keystroke dynamics that include user emotional state detection.

Acknowledgments. This paper acknowledges support from Cloodie R&D.

References 1. Joyce, R.; Gupta, G.: Identity authentication based on keystroke latencies. Commun.

ACM 33, 2 (February 1990), 168-176. http://doi.acm.org/10.1145/75577.75582 (1990) 2. Cho, S.; Han, C.; Han., D. H.; Kim, H. I.: Web based Keystroke Dynamics Identity Verification using Neural Network. Journal of Organizational Computing and Electronic Commerce, Vol. 10, No. 4, pp. 295–307 (2000) 3. Polemi, D.: Biometric Techniques: Review and Evaluation of Biometric Techniques for Identification and Authentication, Including an Appraisal of the Areas Where They are Most Applicable. Institute of Communication and Computer Systems, National Technical University of Athens, Athens, Greece. Retrieved on 2013-0701: ftp://ftp.cordis.lu/pub/infosec/docs/biomet.doc, EU Commission Final Rep. (1997) 4. Araujo, L. C. F.; Sucupira, L. H. R.; Lizarraga, M. G.; Ling, L. L.; Yabu-Uti, J. B. T.: User authentication through typing biometrics features. Signal Processing, IEEE Transactions on, vol. 53, no. 2, pp.851–855 (2005) 5. Monrose, F.; Rubin, A. D.: Keystroke dynamics as a biometric for authentication.

Future Gen. Comput. Syst., vol. 16, no. 4, pp. 351-359 (2000) 6. Killourhy, K. S.; Maxion, R. A.: Comparing Anomaly-Detection Algorithms for Keystroke Dynamics. In International Conference on Dependable Systems & Networks (DSN-09), pp. 125–134, Estoril, Lisbon, Portugal, 29 June to 02 July 2009.

IEEE Computer Society Press, Los Alamitos, California (2009) 7. Mahalanobis, P. C.: On the generalised distance in statistics. Proceedings of the National Institute of Sciences of India 2 (1): 49-55. Retrieved on 2013-07-01: http://www.new.dli.ernet.in/rawdataupload/upload/ insa/INSA_1/20006193_49.pdf (1936) 8. Bradley, A. P.: The use of the area under the ROC curve in the evaluation of machine learning algorithms. Pattern Recognition, Volume 30, Issue 7, July 1997, Pages 1145–1159, ISSN 0031-3203, http://dx.doi.org/10.1016/S0031-3203(96) 00142-2. (1997) 9. Chan, T. F.; Golub, G. H.; LeVeque, R. J.: Updating Formulae and a Pairwise Algorithm for Computing Sample Variances. Technical Report STANCS-79-773, Department of Computer Science, Stanford University. Retrieved on 2013-07-01: ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/79/773/ CS-TR-79-773.pdf (1979)

1472

Gestión Integral de Seguridad de Infraestructuras críticas paralas organizaciones locales alineadas a las Normas IRAM ISO IEC 27.001 y 27002.

Mag. Licenciada Mirta Elizabeth Navarro1 Mag. Abogado María del C. Becerra22, marisabecerra2005@yahoo.com.ar, mirthaenavarro@yahoo.com.ar

Abstract.:Con esta propuesta de gestión integral diseñada para la protección de la información alineada a la norma IRAM ISO IEC 27001, 27002 y a lastendencias y normas de seguridad informática, consistente en la creación y adopción de un marco regulatorio que favorezca la identificación y protección de las infraestructuras estratégicas y críticas de la U.N.S.J., se favorecerá la colaboración entre los diversos sectores públicos y privados, para el desarrollo de estrategias y estructuras adecuadas para la protección de los activos de información. Todo ellodará real importancia a la nueva visión del estado, liderada por la incorporación de las TIC´s en los procesos administrativos y bajo el sustento de la comunicación íntegra y confidencial necesaria en el entorno globalizado de e-gobierno, se busca dar impulso a la administración electrónica.

Keywords: Gestión Integral de seguridad. Infraestructuras críticas. Propuesta para implementar el plan Infraestructuras críticas y ciberseguridad.

1 Introducción Para ayudar a garantizar una gestión de integral de las infraestructuras críticas3 de las empresas se tomaron en cuenta dos normas de la familia de las normas ISO 27000 adaptadas y traducidas en nuestro país, especialmente las Normas IRAM ISO 27.0014 y 270025 y su antecedente 17799), en base a ellas se definieron los requisitos para el sistema de gestión de seguridad (SGSI) propuesto.

En el proyecto “Convergencia de Tecnologías informáticas y Metodologías para la implementación de sistemas de Información”se analizaron las políticas, prácticas, procedimientos y estructuras organizacionales como conjunto de controles necesarios para implementar un sistema de gestión para las infraestructuras críticas.

En Argentina por Resolución 580/2011 se crea, en el ámbito de la Oficina Nacional de Tecnologías de Información de la subsecretaria de Tecnologías de Gestión de la Secretaria de Gabinete de la Jefatura de Gabinete de Ministros, el “Programa Nacional De Infraestructuras Criticas De Información y Ciberseguridad” en el marco de lo establecido la Ley de Ministerios (t.o. Decreto Nº 438/92), a fin de impulsar la creación y adopción de un marco regulatorio específico que propicie la identificación y protección de las infraestructuras 1Licenciada

en Administración de empresas egresada de la U.N.S.J. Magíster en Gestión de Organizaciones egresada de la Universidad de Valparaíso. Chile. Docente de la U.N.S.J. Directora del Proyecto Convergencia de Tecnologías informáticas y Metodologías para la implementación de Sistemas de información 2Abogado, egresado de la UCC. Magíster en Informática egresado de la Universidad Nacional de la Matanza. Docente Investigadora de la U.N.S.J. Directora del Instituto de informática del Foro de Abogados de San Juan 3 Las infraestructuras críticas son aquellas instalaciones, redes, equipos físicos y de tecnología de la información cuya interrupción o destrucción tendría un impacto en el bienestar de los ciudadanos o en el eficaz funcionamiento del gobierno. Las infraestructuras críticas están presentes en numerosos sectores: financiero, transporte y distribución, energía, salud, comunicaciones, y administraciones públicas.

4 En Argentina es IRAM, como organismo nacional de normalización, quien la estudia a través del Subcomité de Seguridad de la Información y la adopta como IRAM-ISO/IEC 27001. Se publica bajo el nombre Tecnología de la información. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos, difundiéndola en la región a través de cursos y seminarios.

5Aprobada y consensuada por el IRAM (Instituto de Normalización Argentino) en el año 2002

1473

estratégicas y críticas del Sector Público Nacional, los organismos interjurisdiccionales y las organizaciones civiles y del sector privado que así lo requieran, y la colaboración de los mencionados sectores con miras al desarrollo de estrategias y estructuras adecuadas para un accionar coordinado hacia la implementación de las pertinentes tecnologías, entre otras acciones.

El “Programa Nacional de Infraestructuras Criticas de Información y Ciberseguridad” no interceptará ni intervendrá en conexiones o redes de acceso privado de acuerdo a lo estatuido por la Ley Nº 25.326 de Protección de los Datos Personales y su Decreto Reglamentario Nº 1558 del 29 de noviembre de 2001.

El programa de ICIC, tendrá a su cargo los siguientes objetivos: a) Elaborar y proponer normas destinadas a incrementar los esfuerzos orientados a elevar los umbrales de seguridad en los recursos y sistemas relacionados con las tecnologías informáticas en el ámbito del Sector Público Nacional. b) Colaborar con el sector privado para elaborar en conjunto políticas de resguardo de la seguridad digital con actualización constante, fortaleciendo lazos entre los sectores público y privado; haciendo especial hincapié en las infraestructuras críticas. c) Administrar toda la información sobre reportes de incidentes de seguridad en el Sector Público Nacional que hubieren adherido al Programa y encausar sus posibles soluciones de forma organizada y unificada. d) Establecer prioridades y planes estratégicos para liderar el abordaje de la ciberseguridad, asegurando la implementación de los últimos avances en tecnología para la protección de las infraestructuras críticas. e) Investigar nuevas tecnologías y herramientas en materia de seguridad informática. f) Incorporar tecnología de última generación para minimizar todas las posibles vulnerabilidades de la infraestructura digital del Sector Público Nacional. g) Asesorar a los organismos sobre herramientas y técnicas de protección y defensa de sus sistemas de información. h) Alertar a los organismos que se adhieran al presente Programa sobre casos de detección de intentos de vulneración de infraestructuras críticas, sean estos reales o no. i) Coordinar la implementación de ejercicios de respuesta ante la eventualidad de un intento de vulneración de las infraestructuras críticas del Sector Público Nacional. j) Asesorar técnicamente ante incidentes de seguridad en sistemas informáticos que reporten los organismos del Sector Público Nacional que hubieren adherido. k) Centralizar los reportes sobre incidentes de seguridad ocurridos en redes teleinformáticas del Sector Público Nacional que hubieren adherido al Programa y facilitar el intercambio de información para afrontarlos.

I) Actuar como repositorio de toda la información sobre incidentes de seguridad, herramientas, técnicas de protección y defensa. m) Promover la coordinación entre las unidades de administración de redes informáticas del Sector Público Nacional, para la prevención, detección, manejo y recopilación de información sobre incidentes de seguridad. n) Elaborar un informe anual de la situación en materia de ciberseguridad, a efectos de su publicación abierta y transparente. ñ) Monitorear los servicios que el Sector Público Nacional brinda a través de la red de Internet y aquellos que se identifiquen como Infraestructura Crítica para la prevención de posibles fallas de Seguridad. o) Promover la concientización en relación a los riesgos que acarrea el uso de medios digitales en el Sector Público Nacional, las Organizaciones de Gobierno, al público en general, como así también del rol compartido entre el Sector Público y Privado para el resguardo de la Infraestructura Crítica. p) Difundir información útil para incrementar los niveles de seguridad de las redes teleinformáticas del Sector Público Nacional. k) Interactuar con equipos de similar naturaleza.

II.-Gestión integral de la seguridad.

A los efectos de garantizar la selección de controles de seguridad adecuados y proporcionales y para proteger la información crítica de las organizaciones se eligieron las Normas IRAM ISO IEC mencionadas porque se consideran recomendables para cualquier empresa grande o pequeña en cualquier parte del mundo y para aquellos sectores que tienen información crítica o gestionan la información de otras empresas.

1474

Para protegerse de estas amenazas la British Standards Institution publicó en 1995 la norma BS 7799 parte 1 y 2- que sirvió como antecedente a ISO para el estudio de dos estándares internacionales adoptados y reconocidos a nivel mundial: la norma ISO/IEC 17799:2000 Information technology - Security techniques Code of practice for information security management, revisada en 2005 y reemplazada por la ISO/IEC 27002, que establece los requisitos fundamentales a tener en cuenta para establecer, operar, controlar, revisar, mantener y mejorar un sistema de gestión de seguridad de la información. La norma 27.002 establece un conjunto de reglas de normalización de los conceptos y operatorias de seguridad informática.

Tal cual lo enfatizan los autores, la seguridad de la información se logra implementando un conjunto adecuado de controles que abarca políticas, practicas, y procedimientos, estructuras organizaciones y funciones del software. Estos controles deben ser establecidos para garantizar que se logren los objetivos específicos de seguridad de la organización”.

La edición 2000 de esta norma fue publicada por IRAM dando como resultado la IRAM-ISO/IEC 17799:2002. Ésta fue estudiada por el Subcomité de Seguridad de la Información de IRAM (revisión de la IRAM 17798 cuyo antecedente es la BS 7799-2).

La norma está basada en el mismo modelo de los sistemas de gestión de la calidad de la familia ISO 9000. Establece conceptos similares sobre Requisitos de la documentación: alcance, política de seguridad, enfoque sistémico de identificación y valoración de riesgos, operaciones para el tratamiento de los riesgos, objetivos de control, controles y aplicabilidad de los mismos.

Actualmente para certificar un Sistema de Gestión de la Seguridad implementado bajo la norma ISO/IEC 17799 (ISO 27002) se utiliza la norma ISO/IEC 27001: 2005.

Tal como lo prevé la Norma IRAM ISO IEC 27.001 para una adecuada gestión de la seguridad de la información se propone implantar en las organizaciones locales un sistema que aborde esta tarea de una manera metódica, documentada y basada en objetivos claros de seguridad y en una evaluación de los riesgos a los que está sometida la información de las organizaciones locales.

En la práctica esta norma se presenta embebida en varias normativas estatales en Argentina. Forma parte de reglamentaciones de organismos del Estado para cumplir con diversos procedimientos, entre los que se destaca la comunicación A4609 del BCRA (Banco Central de la República Argentina). Un decreto del Poder Ejecutivo de la Secretaria de la Función Pública (2006) instaló la norma con el nombre de Sistema de Gestión de Seguridad del Estado. Existen 400 organismos estatales que la implementan pero no la certifican.

La comunicación A-4609 del Banco Central de la República Argentina6, resulta así aplicable al conjunto de entidades del sistema regulado por dicha institución y establece los “Requisitos mínimos de gestión implementación control de los riesgos relacionados con la tecnología informática, sistemas de información y recursos asociados para entidades financieras”.

En el apartado referido a la Gestión de seguridad la comunicación establece que las entidades financieras deben considerar en su estructura organizacional un área para la protección de los activos de información, con el fin de establecer los mecanismos para la administración y el control sobre el acceso lógico y físico a sus distintos ambientes tecnológicos y recursos de información: equipamiento principal, plataforma de sucursales, equipos de departamentales, subsistemas o módulos administradores de seguridad de los sistemas de aplicación, sistemas de transferencias electrónica de fondos, base de datos, canales de servicios electrónicos, banca por Internet y otros.

Por la complejidad de la implementación de la Norma, sería conveniente que la Administración Pública definiera de manera sistemática el alcance el proyecto, principalmente en las áreas de CONTROL DE ACTIVOS Y SEGURIDAD DE LOS RECURSOS HUMANOS. Adoptar una norma de gestión de la seguridad de la información garantiza la correcta consideración de los activos de información de una organización junto con el análisis de su vulnerabilidad y amenazas, también asegura que se establezcan controles de procedimiento y tecnológicos (gestión de accesos mediante registro de huellas, control de información por Internet y mails, controles sobre el software y las bases de datos).

Mediante la norma estos procedimientos se desarrollan de manera ordenada, pautada y controlada; no como simples impulsos aislados, sino como un verdadero sistema que garantice la confidencialidad, integridad y acceso a la información de gestión, de dirección, y pública de la empresa.

A partir de la generalización de la tecnología de la información y la comunicación proliferaron las situaciones de riesgo para los sistemas de información, las bases de datos y los recursos de hardware, a los cuales denominamos activos de la información.

6

B.O. 31.156,16/05/2007, corregida por la Comunicación C-48.583/2007 BCRA y actualizada por la Comunicación B9042/2007 BCRA

1475

Se tomó en cuenta la decisión administrativa 669/2004 que estableció que los organismos del Sector Público Nacional comprendidos en los incisos a) y c) del artículo 8º de la Ley Nº 24.156 y sus modificatorias deberán dictar o adecuar sus políticas de seguridad. Conformación de Comités de Seguridad en la Información. Funciones de los mismos y responsabilidades en relación con la seguridad.

Los comités deberán integrado al menos por un miembro del Directorio o autoridad equivalente, y el responsable máximo del área de Tecnologías Informática y sistemas.

III.- Infraestructuras críticas.

Infraestructuras Criticas son las infraestructuras estratégicas (es decir, aquellas que proporcionan servicios esenciales) cuyo funcionamiento es indispensable y no permite soluciones alternativas, por lo que su perturbación o destrucción tendría un grave impacto sobre los servicios esenciales”. Se refiere tanto a empresas del sector TIC, agua, energía, industria nuclear, sistema financiero o transporte, ente otras.

Las Infraestructuras Criticas, son consideradas un conjunto de recursos, servicios, tecnologías de la información y redes, que en el caso de sufrir un ataque, causarían gran impacto en la seguridad, tanto física como económica, de los ciudadanos o en el buen funcionamiento del Gobierno de la Nación, siendo menester dictar medidas para la protección de tales infraestructuras.

Existen gran variedad de formas de ataque a los sistemas, con el fin de obtener esta información.

Pero también existen políticas y paradigmas de seguridad actuales que nos permiten poner una brecha a estos ataques y proteger este recurso tan valioso.

Tomando en cuenta que el mundo contemporáneo se caracteriza por los profundos cambios originados en el desarrollo y difusión de las tecnologías de la información y la comunicación en la sociedad, las cuales se encuentran sustentadas en gran medida en el ciberespacio. Y que la utilización de las comunicaciones virtuales es un recurso que depende de la infraestructura digital, la cual es considerada como infraestructura crítica, entendiéndose ésta como imprescindible para el funcionamiento de los sistemas de información y comunicaciones, de los que a su vez dependen de modo inexorable, tanto el Sector Público Nacional como el sector privado, para cumplir sus funciones y alcanzar sus objetivos.

En el planteamiento de los instrumentos de planificación, se detectaron cambios estratégicos de protección que hasta ahora estaban enfocados principalmente a la seguridad física y que, ahora, como no podía ser de otra manera tienen un enfoque integral y actual de protección de las Infraestructuras críticas como conjunto de actividades destinadas a asegurar la funcionalidad, continuidad e integridad de las infraestructuras críticas con el fin de prevenir, paliar y neutralizar el daño causado por un ataque deliberado contra infraestructuras y garantizar la integración de estas actuaciones.

Se requiere un planteamiento de seguridad holístico (física, lógica, personal y operativa) de verdadera Seguridad Integral = Protección + Prevención donde la Gestión de riesgos debe ser su protagonista más importante y las soluciones pasen por la Evaluación de Impactos, establecimiento de Planes de contingencia, Planes de continuidad del negocio y de las operaciones y la determinación de los Sistemas y aplicaciones de garantía de alta disponibilidad.

En la Protección de Infraestructuras Críticas, es preciso estudiar los criterios que permitan determinar qué factores confieren carácter crítico a una infraestructura o elemento de infraestructura particular. Los criterios de selección deberían basarse en conocimientos sectoriales y generales. Pueden definirse tres factores de identificación de una infraestructura crítica potencial: • Alcance - la pérdida de un elemento de infraestructura crítico se mide por el tamaño del área geográfica que pudiera verse afectada por su pérdida o indisponibilidad.

• Magnitud - el grado del impacto o de la pérdida puede evaluarse como nulo, mínimo, moderado o principal.

Entre los criterios que podrían utilizarse para evaluar la magnitud potencial se encuentran los siguientes: (a) impacto público (cantidad de población afectada, pérdidas de vidas, enfermedades, lesiones graves, evacuación); (b) económico (efecto PIB, volumen de pérdida económica y/o degradación de productos o servicios); (c) ambiental (impacto en el lugar y sus alrededores); (d) interdependencia (con otros elementos de infraestructura críticos). (e) político (confianza en la capacidad de las administraciones públicas); Efectos en el tiempo - estos criterios determinan en qué plazo (tiempo) la pérdida de unelemento podría tener un impacto. En caso de sufrir un ataque, las estructuras críticas, causarían gran impacto en la seguridad, tanto física como económica del país. Este impacto se mide según unos criterios horizontales que determinan la

1476

criticidad de una infraestructura. Se han establecido tres: el número potencial de víctimas, el impacto económico y el impacto público.

En la República Argentina se enuncia que El Programa Nacional de Infraestructuras Críticas de Información y Ciberseguridad (ICIC) tiene como finalidad impulsar la creación y adopción de un marco regulatorio específico que propicie la identificación y protección de las infraestructuras estratégicas y críticas del Sector Público Nacional, los organismos interjurisdiccionales y las organizaciones civiles y del sector privado que así lo requieran, y la colaboración de los mencionados sectores con miras al desarrollo de estrategias y estructuras adecuadas para un accionar coordinado hacia la implementación de las pertinentes tecnologías.

También impulsa una Encuesta Nacional sobre Acceso y Uso de Tecnologías de la Información y la Comunicación (ENTIC) en Hogares y Personas, que permite contar con información desde la perspectiva de los usos y accesos de los hogares y de las personas a dichas tecnologías en la Argentina. La ENTIC se administró a todos los hogares para la Encuesta Anual de Hogares Urbanos (EAHU), cuya estimación se extiende al total de la población residente en hogares particulares urbanos, en localidades de 2.000 o más habitantes.

Mediante el Programa Nacional de Infraestructura Crítica de Información y Ciberseguridad (ICIC) e Internet Sano - Se promoverá la concientización de la protección de las infraestructuras críticas de información y la ciberseguridad dentro de las dependencias del Sector Público Nacional, brindando asistencia técnica a los organismos nacionales, provinciales y municipales que lo requieran.

- Se actualizará la Estrategia Nacional ICIC. - Se dictarán talleres y charlas técnicas sobre Ciberseguridad.

- Se formularán ejercicios de respuesta a incidentes.

- Se creará la Política de Seguridad de la Información.

- Se generarán nuevos contenidos para concientización de la ciudadanía.

- Se desarrollarán exposiciones y conferencias de concientización.

- Se concertarán alianzas público-privadas para la creación y difusión de contenidos.

Organismo responsable: Subsecretaría de Tecnologías de Gestión. Jefatura de Gabinete de Ministros.

Fecha tentativa: diciembre 2013

IV. Propuesta para implementar en la UNSJ. La Universidad Nacional de San Juan (U.N.S.J.) ha desarrollado una plataforma tecnológica a través de la cual se registra, procesa, transmite y almacena información mediante diferentes activos de Información, que permiten interactuar con la comunidad académica, ciudadanía en general y el personal universitario de todo el país, y como además se reconoce que la información que posee es un bien estratégico para sus fines, por lo que se requiere que sea protegida también su obtención, procesamiento, transmisión y almacenamiento.

Considerando que la Resolución 580/2011 crea, el “Programa Nacional De Infraestructuras Criticas De Información y Ciberseguridad” en el marco de lo establecido la Ley de Ministerios (t.o. Decreto Nº 438/92), a fin de impulsar la creación y adopción de un marco regulatorio específico que propicie la identificación y protección de las infraestructuras estratégicas y críticas del Sector Público Nacional, los organismos interjurisdiccionales y las organizaciones civiles y del sector privado que así lo requieran. Dado que las universidades nacionales como órganos académicos deberían adherirse a lo previsto por la resolución 580/2011 que se creó, en el ámbito de la Oficina Nacional de Tecnologías de Información de la subsecretaria de Tecnologías de Gestión de la Secretaria de Gabinete de la Jefatura de Gabinete de Ministros, el “Programa Nacional De Infraestructuras Criticas De Información y Ciberseguridad” en el marco de lo establecido la Ley de Ministerios (t.o. Decreto Nº 438/92), se impone para la U.N.S.J. la obligación de establecer una Política de Seguridad que fije las directrices generales que oriente la materia de seguridad dentro de cada Unidad.

Para ello se crearía un comité que será el responsable máximo del área de Tecnologías Informática y sistemas. Y que deberá dictar o adecuar sus políticas de seguridad de la Universidad Conformación de Comités de Seguridad en la Información. Funciones de los mismos y responsabilidades en relación con la seguridad.

El encargado de seguridad de los activos de información debería establecer un organigrama de funciones, determinando la cantidad de miembros de la Unidad, cargos y funciones (discriminando quienes son los administradores de seguridad y/o miembros del comité). Tendría además a su cargo el desarrollo y actualización de las políticas de seguridad y controlar su implementación, utilizando como referencia las

1477

Normas IRAM ISO 27.0017 y 270028 y su antecedente 17799) debido a que en base a ellas se definieron los requisitos para el sistema de gestión de seguridad (SGSI) propuesto.

Para ello sería necesario para ello adoptar las medidas para la protección de la Infraestructuras críticas donde se fije entre otras cosas, la necesidad de que para esta gestión se fije: • Un Plan de Seguridad del Operador (PSO) • Un Plan de Protección Especifico (PPE) para cada una de las infraestructuras que haya sido identificada como critica por la Secretaria de para la Protección de Infraestructuras Criticas.

El encargado de seguridad debería recoger los contenidos mínimos que deben articular estos planes, y desarrollar un nuevo documento en el que se describe el modo de abordar la implantación de las medidas y más tarde reflejarlo en dichos planes.

Se entiende por incidente de seguridad todo incidente que impida el normal funcionam8ento de los activos de información y que afecte la Seguridad Informática.

La gestión de incidentes de Seguridad tiene por objeto restaurar la operación normal de los sistemas con tanta rapidez como sea posible y mitigar el impacto adverso a sus procesos, asegurando así que se mantenga debidamente la confidencialidad, integridad y disponibilidad de la información de la U.N.S.J. El comité de Seguridad Informática definirá las pautas a seguir en la gestión de incidentes de seguridad, lo que deberán ser implementados por el Departamento de Sistemas de la U.N.S.J. bajo la coordinación del encargado de Seguridad de los activos de información.

Además deberá elaborar una Guía aplicativa del sistema de seguridad utilizando como apoyo la Norma IRAM ISO IEC 27001.

Se propone un sistema de gestión de Incidentes de seguridad porque es la forma en que la Organización dirige y controla aquellas actividades asociadas a la seguridad. De una manera más amplia debería contar con dos grandes apartados alineados con la estructura del Plan de Seguridad del Operador (PSO) y del Plan de protección Específico (PPE): • Un capítulo dedicado al análisis de riesgos, uno de los aspectos principales de los mencionados planes.

Dos capítulos dedicados a recoger las medidas de seguridad lógicas y físicas que se deberán: • Construir y proponer una normativa de seguridad aplicable al entorno local mediante la • Implementación de un Equipo de Respuesta a Incidentes para la Universidad Nacional de San Juan.

La Metodología propuesta para el Manejo de Incidentes CSIRT9 – UNSJ, básicamente se ha estructurado de acuerdo al siguiente esquema: Cada uno de los pasos propuestos se describe a continuación: 1. Preparación y Protección La fase de preparación consiste, principalmente, en la implementación de un equipo de Respuesta a Incidentes de Seguridad Informática (CSIRT), las actividades propuestas, que se deben realizar en esta fase son: • Planificación del CSIRT – UNSJ • Implementación del CSIRT – UNSJ • Evaluación y funcionamiento del CSIRT • Lecciones Aprendidas.

A más de definir un proceso de implementación de un equipo de CSIRT, es importante tomar en cuenta la Protección de la infraestructura de la Universidad para de esta manera asegurar que los sistemas, redes y aplicaciones tengan un nivel de seguridad adecuado. Las actividades de esta fase se realizan en conjunto con 7

En Argentina es IRAM, como organismo nacional de normalización, quien la estudia a través del Subcomité de Seguridad de la Información y la adopta como IRAM-ISO/IEC 27001. Se publica bajo el nombre Tecnología de la información. Sistemas de gestión de la seguridad de la información (SGSI). Requisitos, difundiéndola en la región a través de cursos y seminarios.

8Aprobada y consensuada por el IRAM (Instituto de Normalización Argentino) en el año 2002 9 Un Equipo de Respuesta ante Emergencias Informáticas (CERT, del inglés Computer Emergency Response Team) es un centro de respuesta a incidentes de seguridad en tecnologías de la información. Se trata de un grupo de expertos responsable del desarrollo de medidas preventivas y reactivas ante incidencias de seguridad en los sistemas de información. Un CERT estudia el estado de seguridad global de redes y ordenadores y proporciona servicios de respuesta ante incidentes a víctimas de ataques en la red, publica alertas relativas a amenazas y vulnerabilidades y ofrece información que ayude a mejorar la seguridad de estos sistemas.

1478

el área de Seguridad, pero básicamente el área de Manejo de incidentes tiene a su cargo la prevención de ataques, y si estos suceden mitigar el impacto. El área de seguridad realiza actividades de protección, en cuanto a configuraciones y garantiza la infraestructura informática de la Universidad.

2. Detección de Incidentes de Seguridad Esta fase está compuesta de varias actividades, tales como: detección de incidentes, análisis inicial y documentación del incidente y tiene como objetivo la búsqueda de toda posible señal de ocurrencia de un incidente. Todas las actividades e información generada en esta fase en enviada al proceso de Triage, haciendo uso de los reportes establecidos.

La Detección de incidentes es un proceso que permite identificar las actividades inusuales que pueden comprometer la misión del CSIRT, consiste en la detección y evaluación de posibles incidentes, determinar si un incidente ha ocurrido, y de ser así, el tipo, extensión y magnitud del problema.

Estas actividades se pueden identificar de manera reactiva y proactiva.

Los incidentes se pueden detectar a través de muchos medios tales como: IDS basados en red (NIDS) y en host (HIDS), software antivirus, software de control de integridad de archivos, sistemas de monitoreo de red, analizadores de logs, etc.

Los incidentes también pueden ser detectados por medios manuales, tales como reportes de incidentes de usuarios.

En el proceso de detección están involucrados: Encargado de Seguridad, CSIRT-UNSJ, Gestión de Servicios TI, Infraestructura de TI, usuarios que han sido víctimas de algún ataque y otras áreas, incluye los siguientes aspectos: • Señales de un incidente • Detección de incidentes mediante la utilización de herramientas • Detección de incidentes mediante el reporte de terceros.

Señales de un Incidente: En el proceso de detección, la información sobre potenciales incidentes, vulnerabilidades, información de seguridad informática o de manejo de incidentes, puede ser obtenida de dos maneras: • Detección Reactiva Un incidente puede haber ocurrido o estar ocurriendo en este momento, puede ser detectado de varias maneras: • El antivirus detecta que un equipo está contaminado con algún tipo de virus.

• Incidentes en el servidor web • Envío de alertas y notificaciones por parte de otras organizaciones.

• Detección Proactiva • Monitoreo de Red • Escaneo de vulnerabilidades • Investigación • Análisis de Riesgos La detección de incidentes es un proceso que permite saber si el sistema está en peligro o si los servidores corren el riesgo de detener sus servicios.

Esta actividad va de la mano con la detección proactiva, se debe tomar en cuenta el personal que se encargue del monitoreo y detección de actividad sospechosa, análisis de logs, uso de software de detección de intrusos, para cada una de estas actividades se deben tomar en cuenta los procesos establecidos en el Área de Seguridad para estas actividades.

Todos los datos analizados y los considerados sospechosos se envían al proceso de Triage.

Detección de incidentes mediante el reporte de terceros va de la mano con la detección reactiva, el usuario notifica del incidente al área de Gestión de Servicios, si el incidente se encuentra en la base de conocimiento de esta área, es atendido por ellos, caso contrario se envía el reporte del incidente al equipo CSIRT – UNSJ, en donde, primeramente se verifica que sea un incidente de seguridad.

Los incidentes que se envían al CSIRT-UNSJ y los que se atienden, son los que constan en la Categorización de incidentes del CSIRT-UNSJ. • Análisis de Incidentes de Seguridad En este proceso se busca analizar cada reporte de incidentes presentado, tanto por los usuarios y por los reportes obtenidos de las herramientas utilizadas, con la finalidad de verificar si realmente se trata de un incidente de seguridad, o son falsos positivos.

1479

Se debe recalcar que el equipo CSIRT debe trabajar rápidamente en el análisis y validación de los incidentes, todas las acciones realizadas deben ser documentadas.

Uno de los mecanismos que sirve de soporte para Detección es la documentación del incidente, se han definido varios formatos para el reporte y respuesta de incidentes y vulnerabilidades, el uso de reportes ayuda a: • Proveer información completa de un incidente al equipo • Organizar la información recibida • Priorizar reportes La información que se solicita en el reporte de incidente es: • Información de contacto • Fecha de reporte • Sistemas afectados • Descripción del incidente • Observaciones A más de los reportes de incidentes, parte de la documentación incluye un documento en el que se detalla el cómo los usuarios deben realizar el reporte de los incidentes al equipo, etc.

Adicional al reporte de incidente enviado por el usuario, por parte del Equipo CSIRT-UNSJ se debe enviar un documento de respuesta a incidentes, en el que se detalle la información relativa a la atención y respuesta del incidente reportado, dependiendo del tipo de incidente, esta información será enviada a autoridades, y personal que requiera de esta información. (Esta sección, se detalla en la fase de la respuesta a incidentes).

En cuanto a los recursos humanos, es necesario que el plantel de empleados sea idóneo para la realización del trabajo de la Organización, pero además debe definir y comunicar sus funciones y responsabilidades.La misma organización debe establecer las necesidad información y facilitar y evaluar la eficacia de la formación y de esto debe haber evidencia (Es decir, se exige un registro de capacitación del personal y en lo posible la formación de una tablero de comando al efecto).

También se debe sensibilizar a toda la organización sobre la importancia de la capacidad humana de la Organización descansa sobre la formación que da a todos sus empleados. La organización dispone un potencial que debe ser aprovechado para poder subsistir y este es el potencial humano para ello se debe implantar los siguientes aspectos motivación, adiestramiento y Comunicación.Implantar en las infraestructuras críticas para mejorar los niveles de protección integrales.

Se propone crear un CSIRT dentro de la UNSJ, ello es un proceso que involucra un cambio estructural, organizacional y desde luego requiere de mucho esfuerzo y compromiso a todos los niveles. Sin duda un CSIRT viene a darle un gran valor a la organización ya que provee un punto de contacto único para afrentar, resolver y proponer en el campo de las nuevas tecnologías.

La protección del ciberespacio requiere de una organización que sirva de centro nacional decoordinación para asegurar y proteger el ciberespacio, cuya misión incluye vigilancia, alerta,respuesta y recuperación, con la colaboración de las entidades gubernamentales en los ámbitosnacional, estatal y local, el sector privado, el sector académico y la comunidad internacional.

Los principales objetivos que debe cubrir este centro nacional son: Desarrollar un sistema nacional de seguridad y respuesta ante incidentes cibernéticos paradetectar, prevenir, responder y recuperarse de incidentes en el ciberespacio.

• Establecer un centro de coordinación para la gestión de incidentes cibernéticos que reúnen los elementos críticos del gobierno y los elementos esenciales de las infraestructuras de los operadores y los proveedores para reducir el riesgo y la gravedad de los incidentes.

• Participar en la vigilancia, alerta y mecanismos de intercambio de información.

• Elaborar y probar los planes de respuesta de emergencia, procedimientos y protocolospara asegurar que los colaboradores gubernamentales y no gubernamentales puedanfomentar la confianza ypuedan coordinarse de manera eficaz en caso de crisis.

La implementación del CSIRT-UNSJ permitirá: • Contar con un equipo capacitado para la atención de incidentes brindando servicios proactivos, reactivos y de aseguramiento de la calidad en temas de seguridad de la información.

• Concientizar a la comunidad universitaria y usuarios finales sobre los riesgos y beneficios del uso de internet, pero, sobre todo de la importancia de tomar en cuenta las medidas de seguridad adoptadas en la Universidad.

1480

Por otra parte como objetivo fundamental el construir y proponer una normativa de seguridad aplicable al entorno local, la implementación del equipo permitirá compartir la experiencia y resultados obtenidos con otras universidades.

Los beneficiarios de la implementación de este proyecto serán principalmente la UNSJ y con la implementación del proyecto: • Otras Universidades, con la finalidad de profundizar y proponer temas de investigación.

• Organizaciones públicas y privadas que mantienen Equipos de Seguridad.

• Empresas y profesionales que brindan servicios de atención de incidentes.

• Participación efectiva de todos los intervinientes en el proyecto.

Hasta la fecha la participación de los integrantes del equipo se ve reflejada en el cumplimiento de las actividades, estas se han realizado acorde a lo planificado.

Se ha involucrado a personal de Marketing para la publicidad del CSIRT. Se han realizado reuniones de Coordinación Se mantuvieron reuniones con: • Grupo de seguridad para la presentación de la metodología para el manejo de incidentes.

• Grupo de Administradores para comunicarles la existencia del CSIRT-UNSJ, uso de reportes de incidentes y políticas.

Se realizaran actividades de Difusión mediante emisión de boletines con tips de seguridad para usuarios, los mismos que se emitirán mensualmente. Como estrategia de marketing, durante el primer mes se emitirán boletines semanalmente, con el objetivo de posicionar el CSIRT-UNSJ en la comunidad universitaria.

• En conjunto con el área de marketing de la UNSJ se está preparando unaestrategia de comunicación para realizar la difusión del CSIRT-UNSJ, lo que incluye boletines informativos, notas periodísticas, etc.

• Emisión de un boletín sobre el CSIRT-UNSJ al área de marketing para que sea difundido a nivel interno en la UNSJ Finalmente la guía deberá incluir un Anexo dedicado a la protección de los sistemas de monitorización y control de procesos e infraestructuras, dada su relevancia en este tipo de infraestructuras, así como un apartado en el que se recogen, de manera exhaustiva, todas las referencias utilizadas.

V. Conclusiones La seguridad de la infraestructura digital se encuentra expuesta a constantes amenazas, que en caso de materializarse pueden ocasionar graves incidentes en los sistemas de información y comunicaciones, por lo que resulta imprescindible adoptar las medidas necesarias para garantizar el adecuado funcionamiento de las infraestructuras críticas.Los riesgos se han incrementado y sofisticado y hay una demanda de mayor eficacia que exige nuevas respuestas que requieren tecnología, eficacia y calidad. Eficacia y calidad que deben ser percibidas por el usuario.

La propuesta para gestión integral de la seguridad de la información diseñada para la protección de la información de las organizaciones locales, basada en las tendencias, normas de seguridad y estándares actuales y la creación y adopción de un marco regulatorio que favorecerá la identificación y protección de las infraestructuras estratégicas y críticas de la U.N.S.J. , promoverá la colaboración entre los distintos sectores y propiciara el desarrollo de estrategias y estructuras adecuadas para la protección de los activos de información de las organizaciones locales.

El proyecto de Creación e Implementación de un CSIRT Académico para la Universidad Nacional de San Juan, tiene como objetivo fundamental, el construir y proponer una normativa de seguridad aplicable al entorno local, la implementación del equipo permitirá compartir la experiencia y resultados obtenidos con otras universidades Nacionales con el objetivo de proponer la creación de una red nacional de CSIRTs académicos y contribuir así a la investigación y desarrollo de metodologías y buenas prácticas que permitan mejorar la seguridad de las redes.

1481

Así hemos de concluir en que, sin duda hoy la responsabilidad y respuesta de una única Seguridad con mayúscula, integral e integrada, pública y privada, es estrictamente necesaria e irreversible.Por todo ello, para un adecuado presente y futuro hay que integrar el sistema de gestión de la Seguridad Pública y la Seguridad Privada hacia una nueva visión común y especial cultura de seguridad sobre la base de las amenazas complejas y la interdependencia e incrementar los recursos de análisis y liberarlos de viejas patologías y rigideces para desarrollar el esquema de Gestión Integral e Integrada de la Seguridad.

VI.-Referencias 31“Evaluación y Seguridad de un Sistema de Información”, por José Alfredo Jiménez http://www.monografias.com/trabajos/seguinfo/seguinfo.shtml 32. “Administración segura de la información: Una experiencia de vinculación entre un ente del estado provincial y la U.N.P.A”. Javier Díaz, L.I.N.T.I. – Universidad Nacional de La Plata http://www.ing.unp.edu.ar/wicc2007/trabajos/ISBD/066.pdf 33. “Propuesta para un modelo de gestión de documentos electrónicos de archivo en la administración pública”- documento de trabajo elaborado por Carlos Alberto Zapata y Nelson Javier Pulido para el comité de gestión de documentos del sistema nacional de archivos 34.http://www.slideshare.net/scarchivistas/propuesta-para-un-modelo-de-gestin-de-documentoselectrnicos-de-archivo-en-la-administracin-pblica Gómez Vieites, Álvaro (2007). Enciclopedia de la Seguridad Informática.

3.5Altmark, Daniel Ricardo y Molina Quiroga Eduardo. Tratado de Derecho Informático. Tomo III. Publicado por la Ley año 2012

1482

Model Design for a Reduced Variant of a Trivium Type Stream Cipher Antonio Castro Lechtaler1, Marcelo Cipriano1, Edith García2, Julio Liporace2, Ariel Maiorano2, Eduardo Malvacio2, Escuela Superior Técnica “Gral. Div. Manuel N. Savio”, Facultad de Ingeniería Instituto de Educación Superior del Ejército Argentino 1

2

{acastro, marcelocipriano}@iese.edu.ar; {edithxgarcia, jcliporace, maiorano, edumalvacio}@gmail.com

Abstract. We analyze the family of stream ciphers N-viums: Trivium and Bivium. We present the Trivium algorithm and its variants. In particular, we study the NLFSRs used in these generators, their feedback functions and their combination. Two reduced variants of these models are presented, labeled Toys. Finally, we delve into the open problems ingrained in these cryptosystems.

Keywords: LFSR, NLSFR, Trivium, Bivium, Trivium-Toy, Bivium-Toy.

1 Introduction The revolution of communications and technology has taken cryptology from the military and diplomatic realm into everyday life.

E-mailing, home banking, user authentication in social networks, mobile communications, and wireless technology have increased the requirements for confidentiality while data is transferred via insecure channels.

Some ciphering systems meet the requirements to protect data satisfactorily.

However, they do not meet the increasing demand for higher transfer rates.

Because of the resources used and the processing power required, the existing algorithms lag behind the increasing needs for data transfer security.

Stream ciphers may prove suitable to use in portable devices. Their hardware adaptability turns them into feasible solutions, responding to the increasing demand and high transfer rate standards.

1.1 Stream Ciphers.

A perfect cryptosystem entails the capacity for an algorithm to cipher a message which can be deciphered only by the intended receiver.

1483

Vernan and Mauborge created such a system in 1917 at the AT&T labs. In their design, the required key is as long as the length of the message. Both, transmitter and receiver must have the key which must be destroyed after use. Otherwise, security is jeopardized.

Because of this feature, the system is known as One-Time-Pad. The key must be random and is used for both processes: ciphering and deciphering. Hence, users need to share it at both ends. Cryptosystems under this particular secret key configuration belong to a class known as symmetric-key algorithms.

In 1949, Shannon demonstrated the invulnerability of this system by satisfying the requirements for perfect secrecy established by the rising field of Information Theory.

Nonetheless, two weaknesses become apparent, not in the algorithm itself, but in its application. On one hand, a problem arises in the generation of the secret key; and, on the other, in the security of key distribution.

A possible solution is to find a deterministic procedure to generate the key. Such a key would not be random, but pseudorandom, and shall meet additional requirements to be considered secure.

1.2 LFSRs and Non-LFSRs Currently, Linear Feedback Shift Registers (LFSRs) are used extensively to generate pseudorandom sequences with controlled period and linear complexity.

Research on LFSRs began in the 60s [6] and continued through several years. A significant number of results and applications have been produced: algorithm design, error control codes, and linear complexity analysis of binary sequences with the Berlekamp-Massey algorithm [7].

Because of their linearity, LFSRs alone are insecure. It is widely known that, when 2n-1 consecutive bits of an outbound sequence are known, it becomes predictable.

Attempts to add linear complexity by combining LFSRs with, among other things, nonlinear functions have not met the desired standards yet.

Nonlinear Feedback Shift Registers (NLFSRs), a generalization of their linear counterparts, have been relegated for a long time. While LFSR theory is robust and well understood, many fundamental problems with NLFSRs remain unanswered.

One such problem is the determination of the period of outbound sequences in NLFSRs. In recent years, research has focused on nonlinear registers and stream ciphers using NLFSRs in some form. This is the case for the class TRIVIUM [1][2], BIVIUM [10].

Our research focuses in the development of a new family of the TRIVIUMBIVIUM stream cipher class, designated as Toys.

In our Toys, in which the sizes of the NLFSRs are reduced significantly, we have modified their taps while maintaining the original design principles.

With these models, observation in a constrained environment may foster more realistic research projects, as well as allow researchers to compare results within smaller samples and to conduct tests in a reduced space.

In the future, the Toy family may help contribute in the development of a solid algebra involving NLFSRs, in particular for generators of the TRIVIUM-BIVIUM class.

1484

2. FSR Overview An n-bit feedback shift register (FSR) is an n-bit length register with a feedback function: f:{0,1}n →{0,1}

(1)

where the feedback bit (at the tap positions of the register) or the output bit is of the form: xn+t = f(xn-1+t,xn-2+t ,…….xt) (t≥0)

(2)

For each step t, the register bits shift one position to the right and the taps are fed into the function and become the bit input for the following step. The n bits of the register constitute the state of the register at step t. The initial state is defined when t=0. The period of a FSR is the length of the largest cycle generated by the output sequence of the register.

If the feedback function is linear, i.e.: f(xn-1,xn-2 ,…….x0) = c0x0 + c1x1 + c2x2 +………+ cn-1xn-1 (ci ∈ {0,1})

(3)

we say that the registry is an LFSR (Linear Feedback Shift Register). Otherwise, with a nonlinear feedback function, we have a NLFSR (Nonlinear Feedback Shift Register).

Fig.1: n-bit FSR Structure.

In the LFSR case, when the coefficients ci belong to a primitive polynomial, the LFSR output sequence has a maximum length of 2n-1, regardless of the chosen initial (non-trivial) state. The LFSR output sequences of maximum length are called maximal sequences or m-sequences [6]. If 2n-1 output bits of an n-length LFSR are known, then the sequence becomes predictable using the Berlekamp-Massey algorithm [10].

NLFSRs are more robust to algebraic attacks. However, no systematic and efficient method is known to construct secure NLFSRs [3][4]. Furthermore, for a given nonlinear feedback function, it is difficult to predict the period of the output sequence.

A stream cipher is a symmetric ciphering system which takes a sequence of plaintext and a secret key, and operates on the plaintext, generally bit by bit with the key bit stream, generated by the secret key and the algorithm.

1485

Fig.2 Stream Cipher Example The key bit stream must meet certain cryptologic security conditions, i.e.: the length of the sequence and the linear complexity must be sufficiently large, and the binary sequence must satisfy a series of pseudo-random tests [6].

3. Trivium and Bivium The stream algorithm TRIVIUM was designed by Christophe De Cannière and Bart Preneel. It was selected as a finalist algorithm in the e-STREAM Project [5]. It was designed to generate at least 264 bits with the use of an 80-bit secret key and an initialization vector (IV) of also 80 bits.

Fig.3: Trivium algorithm It consists of three combined NLFSRs. The first register controls the second, the second controls the third, and this last register controls the first.

Fig.4: Trivium-Like Structure The core idea behind the design focuses on using the principles of block cipher construction in order to create equivalent components in stream ciphers.

1486

The output consists of three combined non-linear shift registers of length 93, 84, and 111, and where specific positions are selected to obtain a key bit stream. Whereas no efficient attack has been encountered to break this generator so far [8][9], its period remains undetermined and an open research problem.

A complete description is given by the following simple pseudo-code: INPUT: s0, s1,…,s287 initial state, integer n, si ∈{0,1}.

OUTPUT: binary sequence {kt} 1. Initialization t1 ← s65 ⊕ s92 t2 ← s161 ⊕ s176 t3 ← s242 ⊕ s287 2. While ( t<n ) do the following: 2.1 2.2

2.3

kt ← t1 ⊕ t2 ⊕ t3 t1 ← t1 ⊕ s90 ⊗ s91 ⊕ s170 t2 ← t2 ⊕ s174 ⊗s175 ⊕ s263 t3 ← t3 ⊕ s285 ⊗s286 ⊕ s68 (s0, s1,…,s92) ← (t3, s0,…,s91) (s93, s94,…,s176) ← (t1, s93,…,s175) (s177, s178,…,s287) ← (t2, s177,…,s285)

3. Return {kt}

Note that ⊕ is the XOR operation and ⊗ the AND operation.

BIVIUM was designed by Hårvard Raddum to obtain a reduced sized version of TRIVIUM. It consists of two combined NLFSRs (while TRIVIUM has three) of lengths 93 and 84.

Despite the improved security under specific attacks granted by this model, the results are not entirely satisfactory.

4. The Toy Model We present reduced variants of TRIVIUM and BIVIUM algorithms as a strategy to tackle the open problems discussed and the mathematical theory behind the behavior of NLFSRs. The reduced models (decimated by 3) are based on previous work by Yun Tian et al, who developed an extended model of the TRIVIUM structure [11].

We have named these models Toys, considering they are miniatures of the originals.

It is noted that every reduction of a model focuses on a quest for simplicity in its mathematical study and it is not meant to be used in operative information security environments.

1487

We assume the following: A1) Property invariance after size reduction: the reduced size structure of the models maintains the mathematical properties of the original model.

A2) Computational complexity reduction: The reduction in size contributes to a reduction of the problem, making the model more manageable under computational as well as algebraic considerations.

A3) Property invariance after size increase: In the case of identified patterns in the behavior and mathematical properties in the reduced model, they may be extrapolated to the original model.

These assumptions need to hold throughout the entire research. In case one of them does not hold or inconsistences among them are encountered, the procedure presented here ought to be revised.

4.1. Trivium-Toy The model consists of three NLFSRs X, Y, and Z of lengths 31, 28 and 37 with the following states: X(31): X0, X1,…………,X30 Y0,Y1,………….,Y27 Y(28): (4) Z0, Z1,………….,Z36 Z(37): Being the feedback of each register, i.e. the bit input in each: X0: Z21 ⊕ Z36 ⊕ Z35 ⊗ Z34 ⊕ X22 Y0: X21 ⊕ X30 ⊕ X29 ⊗ X28 ⊕ Y25 Z0 : Y22 ⊕ Y27 ⊕ Y26 ⊗ Y25 ⊕ Z28 and the key bit stream: Kt:X21 ⊕ X30 ⊕ Y22 ⊕ Y27 ⊕ Z21 ⊕ Z36

(5)

(6)

Also, the cipher of the plaintext with the key bit stream is: Ct = P t ⊕ K t

(7)

Fig.5 Trivium vs Trivium Toy

1488

Pseudo-code of the Trivium is changed to a reduced form as follows: INPUT:

s0, s1,…,s95 initial state, integer n, si ∈ {0,1}.

OUTPUT: binary sequence {kt} 1. Initialization. t1 ← s21 ⊕ s30 t2 ← s53 ⊕ s58 t3 ← s80 ⊕ s95 2. While ( t<n ) do the following: 2.1

kt ← t1⊕ t2 ⊕ t3

2.2

t1 ← t1 ⊕ s28 ⊗ s29 ⊕ s55 t2 ← t2 ⊕ s56 ⊗ s57 ⊕ s87 t3 ← t3 ⊕ s93 ⊗ s94 ⊕ s22

2.3

(s0, s1,…,s30) ← (t3, s0,…,s29) (s31, s32,…,s58) ← (t1, s31,…,s57) (s59, s60,…,s95) ← (t2, s59,…,s94)

3. Return {kt}

4.2. Bivium-Toy The model consists of two NLFSRs X, and Y of lengths 31 and 28 respectively with the following states: X(31): X0, X1,…………,X30 (8) Y(28): Y0, Y1,…………,Y27 Being the feedback of each register: X0: Y22 ⊕ Y27 ⊕ Y26 ⊗Y25 ⊕ X22 Y0: X21 ⊕ X30 ⊕ X29 ⊗X28 ⊕ Y25

(9)

and the key bit stream: Kt:

X21 ⊕ X30 ⊕ Y22 ⊕ Y27

(10)

The cipher process is the same as detailed in formula (7).

Pseudo-code of this reduced cipher is given below: INPUT:

s0, s1,…,s58 initial state, integer n., si ∈ {0,1}.

OUTPUT: binary sequence {kt}

1489

1. Initialization. t1 ← s21 ⊕ s30 t2 ← s53 ⊕ s58 2. While ( t<n ) do the following: 2.1 kt ← t1⊕ t2 2.2

2.3

t1 ← t1 ⊕ s28 ⊗ s29 ⊕ s55 t2 ← t2 ⊕ s56 ⊗ s57 ⊕ s22 (s0, s1,…,s30) ← (t2, s0,…,s29) (s31, s32,…,s58) ← (t1, s31,…,s57)

3. Return {kt}

5. Conclusions In this article we present the class of Trivium-Bivium random sequence generators using non-linear shift registers (NLFSR).

Because of their size, several research problems remain unanswered: patterns of behavior, algebraic properties, period lengths, and weak keys among others.

Under this framework, we present reduced sized variants of these generators for research and applications in cryptology, laying out the formulae of the feedback functions as well as the key bit streams. We assume that the properties identified in the reduced sized models would remain invariant in the original ones.

6. Further research.

The Toy family may foster additional research in the following areas: - Search for length of the period or cycles.

- Distribution of taps and their changes to determine algebraic properties and personalization of N-viums.

- Algebraic analysis of the non-linear functions used in the models.

- Search for possible weak keys.

7. Acknowledgements The financial support provided by Agencia Nacional para la Promoción Científica y Tecnológica (Project PICTO 11- PICTO 11-18621) is gratefully acknowledged.

1490

8. References 1. De Canniére, C. and Preneel, B. “TRIVIUM A Stream Cipher Construction Inspired

by Block Cipher Design Principles”. In Workshop on Stream Ciphers Revisited, (2006).

2. De Canniére, C. and Preneel, B. “TRIVIUM Specifications”. eSTREAM, ECRYPT Stream Cipher Project, Report. (2008).

3. Dubrova, E. “A List of Maximum-Period NLFSRs”, Cryptology ePrint Archive, Report 2012/166, March 2012, http://eprint.iacr.org/2012/166 4. Dubrova, E. “A scalable method for constructing Galois NLFSRs with period 2n −1 using cross-join pairs”. Technical Report 2011/632, Cryptology ePrint Archive, November 2011. http://eprint.iacr.org/2011/632.

5. eSTREAM: eSTREAM – The ECRYPT Stream Cipher Project: http://www.ecrypt.eu.org/stream/ 6. Golomb. “Shift Register Sequences”. Aegean Park Press (1982).

7. Massey, J.L. “Shift-register synthesis and BCH decoding”. IEEE Transactions on Information Theory 15 (1969).

8. Maximov, A. and Biryukov, A. “Two Trivial Attacks on Trivium”, Selected Areas in Cryptography, Lecture Notes in Computer Science, Vol.4876, Springer, 2007.

9. McDonald, C. and Pieprzyk, C. “Attacking Bivium with MiniSat”, Cryptology ePrint Archive,Report 2007/040 (2007).

10. Raddum, H.“Cryptanalytic Results on Trivium”, eSTREAM, ECRYPT Stream Cipher Project, Report 2006/039 (2006).

11. Yun Tian, Gongliang Chen, Jianhua Li: “On the Design of Trivium”. IACR Cryptology ePrint Archive (2009).

1491

Usability Support Security Patterns Susana Romaniz1, Marta Castellaro1, Juan Carlos Ramos1, Ignacio Ramos1 1

Facultad Regional Santa Fe - Universidad Tecnol贸gica Nacional, Lavaise 610 (S3004EWB) Santa Fe Argentina {sromaniz, mcastell, jramos, iramos}@frsf.utn.edu.ar

Abstract. The main feature of secure software lies in the nature of processes and practices used to specify, design, develop and implement software. Security patterns applied the concept of pattern in the security realm. Its description helps to capture immediately the essence: what is the problem to which attends and what the proposed solution is. The different formats that exist for its description and the multiplicity of sources make its discovery demand effort that discourages the systematic use by potential recipients. This paper presents the prototype of a catalogue that seeks to establish a bridge between the knowledge and experience security experts and the needs of knowledge of software development teams.

Keywords: Security patterns. Security intelligence. Security patterns catalogue.

1 Security in the software development process The main feature of secure software lies in the nature of the processes and practices used to specify, design, develop and deploy the software [1]. A project that adopts an improved security software development process incorporates a set of practices that reduce the number of exploitable flaws and bugs. Over time, these practices become more systematic, so it should decrease the likelihood that such vulnerabilities are present in the software at the moment that releases. The results in the field of research and experiences in the industry indicate the importance of reducing such potential vulnerabilities as early as possible within the software development lifecycle. The adoption of improved security processes and practices is much more profitable than the solution widespread today to develop and release patches for the operating software [2].

This early attention of the security has to do with the adoption of a set of activities that make possible the security integration in the software development lifecycle [3], including [4]: 1) identify security objectives, 2) apply security design guidelines, 3) create threat models, 4) conduct security architecture and design reviews, 5) complete implementation security reviews, and 6) run deployment security reviews.

We note the active development of tools and methods for testing that allows assessing the robustness and resilience of software products and their underlying infrastructure under attack conditions (for example, those used in penetration testing). Namely, there is intelligence domain of attacks that exploit vulnerabilities and compromise the security of software-intensive systems. All this produces a complex deal scenario.

There are criteria that help to secure software production [5]:

1492

Keep in mind that the security and cost of production of a software system depends strongly on the knowledge about its requirements [6].  Include security treatment in each of the different stages of the software development cycle is an accepted criterion for improving the security of the final product. [7]  Incorporate security patterns, which represent the best practices achieved by the industry in order to stop or limit security attacks [8].

In the secure software development process’ case, security patterns are a way to bridge the gap between theory and practice. Although there are theoretical approaches, they are limited to relatively complex systems, and require a grade of knowledge and experience that is not available at the necessary level.

Then, we may infer that promote the use of security patterns to guide and drive the building of secure software development models, from the early stages of the process, is an approach that will allow us to ensure greater security in the behavior of a software product. 

2 Security Patterns The concept of “pattern” is known by the community as a solution to common problems in software development, whose effectiveness has been verified by solving similar problems in the past and that is reusable (applicable to different design problems in various circumstances). In the case of the security software aspects, which are found throughout all phases of development, its original definition [9] states that: “Each pattern is a three-part rule, expressed as a relation between a certain context, a certain system of forces that occur repeatedly in this context, and a certain software settings that allows these forces to resolve themselves.”

Extending the concept to software security, security patterns documented well known solutions to recurring problems of information security, allowing an efficient transfer of experience and knowledge. They apply the pattern concept to the realm of security, describing a particular recurrent security problem occurring in a specific context and presenting a well-proven generic solution accepted by the community of experts [10]. To make explicit the assumptions under which apply their solutions are applicable, reduce the risk of inappropriate use.

The solution proposed by a security pattern consists of a set of interacting roles that can be organized in multiple structures (applicable to the phases of requirements analysis, design, coding, testing or implementation, as appropriate pattern) concrete, as well as a process to create a particular structure in these [8]. According to what is expressed in [11] “a pattern defines a process and a thing: the ‘thing’ is created by the ‘process’.” Security patterns can be categorized according to a point of view associated with a software development lifecycle [12]. In this way there are patterns to the requirement phase, patterns to the design phase and patterns for the implementation phase. In general terms, guide the analysis through the context of security patterns allows integrate the problem addressed and the forces present that determine the problem.

Specifically, highlights the following advantages in the use of an approach to the use of patterns in security treatment: (i) express the basics security in a structured and understandable way; (ii) its representation is familiar to software developers and system

1493

engineers, a key part of their audience; (iii) the patterns already are used to capture the knowledge about the system and the organization, then using the patterns to capture security knowledge help to improve security in the systems lifecycles, where results clearly needed. In particular regard to its development, in the last years different security groups have been specifying different patterns, as well as have made efforts for classification purposes [13, 14].

2.1 Security patterns description Often refers to the model POSA (Pattern-Oriented Software Architecture) model developed by Buchman and others [15] to describe the context and the use of security patterns. But you can also see the existence of different descriptive models [16]; even, in many cases they are described so that the model is no strictly respected. These are discussed in detail in [17]. With regard on the format adopted for the description of security patterns, in general, it adopts the definition of a template, which contains a series of named elements and a defined scope. A good description will help to capture immediately the essence of a pattern, i.e., what is the problem to which attends and what is the proposed solution. It also offers all the details necessary to implement it and consider the consequences of its application.

It is important to note that not all fields are required. For example, in the case of some patterns is difficult or unnecessary to provide detailed descriptions of their structure, behavior and the implementation, because the information can be well integrated in the description of the solution. Likewise, in [18, 19] have defined other formats for the description of security patterns, also based on templates defined as sets of named elements and associated scope. A preliminary analysis of the different types of templates shows that there is not an exact match between the elements and scope, although all of them captured approximately the same aspects of security pattern to describe it. In [17] presented the results obtained with respect the variability of the aspects used for the formal definition of security patterns, which were obtained from a in-depth review of 364 security patterns collected from different sources, which were published during the years 1997-2012. These review also allowed us to see very high heterogeneity on the way of naming the aspects and there are no criteria of correspondence between the different names, such as exits between the descriptions of GoF and POSA [20].

2.2 Corporate and community knowledge compilation But already there is no denying the need to address the problem of security products and services based on software, responsible for projects still face serious difficulties in addressing effectively the priorities identified in terms of security. What is the cause of this discrepancy? We cannot say that only due to ignorance about the existence of attackers who manage to exploit vulnerabilities in software. In fact, we can observe a significant disconnect between security experts and software development teams; the first are focused on the security of a system, while the seconds in building a system. For the latter, security is one of the non-functional goals with relevant, but just one of many.

1494

Security patterns constitute a technology adopted for the description, communication and knowledge sharing, and proposed as a bridge that seeks to reduce this gap by capturing security expertise in the form of verified solutions to recurring problems. It is expected that they will be understood and used by the different members of development teams that are not security experts. Since the emphasis is on security, these patterns capture the strengths and weaknesses of different approaches in order to allow development teams to make informed decisions that balance security with other objectives.

We must emphasize that in this paper we have adopted the intelligence concept to refer to the set of practices that give rise to a collection of corporate knowledge, which is used to carry out proactive software security activities across the organization.

We decided to work in the organization and accessibility of that intelligence, seeking to generate a proposal for cataloguing security patterns. So we have considered the possibility of having resources that allow you to access a repository where reference to the set of defined security patterns in a systematic way of special importance. In this way, we hope to put at the disposal of the different actors involved in the software development process (project leaders, architects, designers, QA managers, programmers, testers) this knowledge drawn from the real world on the basis of the experience of specialists in security.

2.3 Cataloguing security patterns At present, a multiplicity of sources exists where there are available different groups of security patterns defined throughout the time. This does that its discovery demands a level of effort that, normally, discourages to whom they are destinated to make use of them in systematic form. A centralized catalogue is a tool that acts as a starting point for the search and identification of one or more solutions to a security problem that is intended to resolve, expressed through security patterns. In this way it seeks to establish a bridge between the intelligence developed by security experts and the needs of knowledge of the software development teams.

To do this, we define as main requirement that the information offered by the catalogue be appropriate to â&#x20AC;&#x153;findâ&#x20AC;? the security pattern. This information is extracted or inferred from the description of the pattern itself, and includes extensions that facilitate the categorization of the pattern according to established criteria. In the current design of the catalogue we adopted two criteria: (1) the security attributes impacted by the problem described; (2) the software development process phase to which applies the pattern. In this way, we hope that the information related with security patterns presented via the catalogue helps to capture immediately the essential aspects of them.

3 Proposal for cataloguing and its contribution Our problem then is to define a way of structuring and indexing a catalogue of security patterns, so it could result quite easy to find a pattern that proposes a solution to an identified security situation, and from there access to the complete original reference of

1495

the security pattern description. We define the set of attributes shown in Table 1 as the common attributes of security patterns that allow finding their references.

Table 1. Attributes for describing security patterns.

Nombre Objetivo Clasificación Aspecto seguridad afectado Keyworkds Referencias

Name of the original definition security pattern.

Problem that the security pattern meets. It is a response to a security problema.

Based on the phase of the software development process in which normally the pattern applies: requirements, analysis, design, coding, testing, implementation.

Confidentiality, integrity, availability, accountability, non-repudiation They serve as a complementary reference to the security pattern.

Links towards the documents and/or web pages where one finds the detailed description of the pattern.

Except for the ‘Nombre’ attribute, for the remaining attributes is necessary to make an analysis of the security pattern description in its original source, extract the attributes concepts associated with the selected attributes and perform the cataloguing of the security pattern. With respect to this concepts extraction process during the review of a security pattern, we found a guide in [17]; this paper summarized the results about the quality of the information included in the aspects that describe a security pattern, as well as the frequency of use of these aspects used along 67 publications of security patterns.

In this regard, we can highlight the following as a guide to the extraction process:  Solution (present in 87% of publications), is used to describe what security aspects attends the pattern and how it could be implemented;  Problem (present in 84% of publications), in many cases includes abstract or oversimplified description of the problem;  Related Patterns and Consequences (present in 75% of publications), require a good understanding of other security patterns as potential impact in the field of security so that they can be used as elements of distinction.  Context (present in 49% of publications) generally includes a brief description, which makes it difficult to extract sufficient knowledge or even an idea about what the security pattern;  Known Use (present in 46% of publications), described in what real-life cases you can use the pattern and provides guidance on its application domain.

4 Cataloguing process and prototype Here by means of an example, the description of the process of incorporation of a security pattern to our catalogue. The selected pattern is called Authenticated Session [21], which is summarized in Figure 1. This process consists in the reading and analysis of the description security pattern conducted by a security expert, and in obtaining the data shown in Table 2, which result from the following references (the latter depends on the particular format adopted by the authors for the description of the security pattern and the quality of associated information): i) Objetivo: it is inferred from the Abstract section of the description; ii) Clasificación: the security expert who performs the reading and analysis of the security pattern inferred that the

1496

Authenticated Session (a.k.a. Server-Side Cookies, Single Sign-On) Abstract An authenticated session allows a Web user to access multiple access-restricted pages on a Web site without having to re-authenticate on every page request. Most Web application development environments provide basic session mechanisms. This pattern incorporates user authentication into the basic session model.

Problem HTTP is a stateless, transaction-oriented protocol. Every page request is a separate atomic transaction with the Web server. But most interesting Web applications require some sort of session model, in which multiple user page requests are combined into an interactive experience. As a result, most Web application environments offer basic session semantics built atop the HTTP protocol. And the protocol itself has evolved to provide mechanisms -such as basic authentication and cookies- that allow session models to operate correctly across different Web browsers. An obvious use for session semantics is to allow users to authenticate themselves once instead of every time they access a restricted page. However, great care must be taken when using session semantics in a trusted fashion. Most session mechanisms are perfectly adequate for tracking noncritical data and implementing innocuous transactions. In such cases, if an end user circumvents the session mechanism, no harm is caused. But it is easy to make mistakes when applying session mechanisms to situations where accountability, integrity, and privacy are critical.

Solution An authenticated session keeps track of a user’s authenticated identity through the duration of a Web session. It allows a Web user to access multiple protected pages on the Web site without having to reauthenticate him/her-self on every page request. It keeps track of the last page access time and causes the session to expire after a predetermined period of inactivity. …..

Examples Many significant Web banking and e-commerce applications rely on this pattern. Any site that enforces user authentication and does not store that information on the client uses something similar. ….

Related Patterns · Network Address Blacklist – a related pattern that demonstrates a procedure for blocking a network address from further access attempts if a session identifier guessing attack is conducted. · Password Authentication – a related pattern that presents the secure management of passwords, which are almost always used as the authentication mechanism for this pattern.

References [1] Coggeshall, J. “Session Authentication”. http://www.zend.com/zend/spotlight/sessionauth7may.php, May 2001.

[2] Cunningham, C. “Session Management and Authentication with PHPLIB”. http://www.phpbuilder.com/columns/chad19990414.php3?page=2, April 1999.

[3] Kärkkäinen, S. “Session Management”. Unix Web Application Architectures. http://webapparch.sourceforge.net/#23, October 2000.

Figure 1. Selected security pattern to cataloguing: Authenticated Session [21].

Table 2. Data for cataloguing the security pattern selected.

Nombre Objetivo Clasificación Aspecto de seguridad afectado Keywords Referencias

Authenticated Session Allow the access to multiple pages with restricted access, without having to re-authenticate again and again.

Keep authentication information in the system’s navigation Design Accountability, Integrity.

Authentication, Single Sign-On  Security Patterns Repository v1.0.pdf  Cunningham, C. “Session Management and Authentication with PHPLIB”. http://www.phpbuilder.com/columns/chad19990414.php3, (Rev. Mayo 2013).  Kärkkäinen, S. “Session Management”. Unix Web Application Architectures. http://webapparch.sourceforge.net/#23, October 2000.

(Rev. Mayo 2013)

1497

same applies to the design phase, in the aspect of ‘user authentication’; iii) Aspecto de seguridad afectado: in the final paragraph of section description Problem refers to “But it is easy to make mistakes when applying session mechanisms to situations where accountability, integrity, and privacy are critical”, accordingly, the security pattern seeks to address these shortcomings; iv) Keywords: inferred from Name and Know-As-As sections; v) Referencias: from the references listed in the References section, selecting those sources whose availability at the time of cataloguing can be verified. Obtained these data, we proceed to cataloguing the security pattern selected for example, using the prototype that we describe in the following section.

To realize this proposal, we analyzed extended use alternative tools that allow us to its implementation. We define build a prototype using a tool for management of bibliographic references: ‘JabRef’. This is a very low-cost alternative to test the idea which, if it actually works, can then be extended to massive tools, as for example a web application with features ‘wiki’.

JabRef is configurable bibliographic reference management software. It use native format BibTex (a text-based and independent of the style file format) to define lists of bibliographic items, articles, thesis, etc. For the generation of the proposed catalogue we take advantage of this facility for recording references in this manager; in addition, the existence of distinct and specific attributes in each pattern allows us to generate a special entry type (Security Pattern type) with their respective fields and general and/or optional information. Another important feature of JabRef is the use of LaTeX, which allows us to transfer automatically and without major difficulties (given the use of welldefined parameters) the current catalogue to any other type of software that allows the entry of the same language: databases, Wikipedia pages, another specific or general purpose manager, etc. Figure 2 shows a screen from the JabRef interface, where:  Groups (section 1). Created groups that correspond to the phases of software development in which the pattern is normally applicable. Selecting a group in section 2 (Entry) will appear the patterns that correspond to that classification.  Entry (section 2). Entries loaded at the base are presented as a table with the fields as columns, which can be used to select a criterion of order by pressing the desired column. You can see all the references or related files by right clicking

1

2

3

4

Figure 2. JabRef Catalogue Interface.

1498

on the desired row in the column ‘File’ (second column), folding a list of values.

If you select one of these, will go to the required reference, whether a document available locally or on the Internet.  Search (section 3). It allows to search according to an attribute and filters inside the entire catalogue. After a search and already showing the selected patterns that contain the phrase or word searched, when you double-click on them and navigating through the different tabs of the query, words appear highlighted in blue.  Preview (Section 4). It shows the information of the security pattern selected in PDF format, which is a friendly representation of the contents of the pattern by default. By pressing the right mouse button you can print preview.

This figure shows the way how catalogued information relating to the Authenticated Session pattern [21] is displayed, where there are the attributes proposed to categorize a security pattern.

Cataloguing a security pattern: Figure 3 shows some of the facilities offered by the developed prototype to incorporate information from the attributes listed in Table 2: Figure 3.a): Loading the ‘Required Fields’ (mandatory): name, objective, classification, security issues, key words and Bibtexkey (a peculiarity of JabRef and

a) Required Fields.

b) Optional Fields.

1499

c) Loading ‘Keywords’ and ‘Referencias’.

Figure 3 Interfaces for loading data for cataloguing attributes Authenticated Session security pattern.

bibtex references, which is used for references to the security pattern); Figure 3b) Information is supplemented with related patterns and other well-known names (in both cases, if any); Figure 3.c): Defining ‘Keywords’ and ‘Referencias’ for the security pattern, taking advantage of the JabRef’s facility for linking local and external files as ‘Files’.

Searching a security pattern in the catalogue: Figure 4 shows the result of a search for references to security patterns applicable to the design phase and that attend to the confidentiality as a security attribute.

Figure. 4. Results of a search in the security pattern catalogue.

5 Conclusions and Future Work This proposal aims to provide to the security community these quick references, and go replenishing it as it’s used. The tool chosen to build a catalogue of references

1500

helps us to test in a simple way, and eventually modify, the proposed structure and criteria, and consider the possibility of replace with another with higher performance and style. This prototype allows us to define the bases to make an extension to a wiki-style web tool, which will be available to the whole community, and also to be updated by it. In addition to the web tool, it will be necessary to propose and publish criteria to incorporate new references to our catalogue, so that all entries follow these agreed common criteria. This is the work that we intend to address in a next phase.

References 1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

McGraw, G., “Software Security: Building Security In.” Addison-Wedsley. EEUU. (2006).

Romaniz, S., “Buenas prácticas de elicitación de los requerimientos de seguridad”. IV Congreso Iberoamericano de Seguridad Informática -CIBSI2007-, Argentina (2007).

Meier, J. et al., “Security engineering explained.” (2005). Available in http://www.microsoft.com/download/en/confirmation.aspx?id=20528.

Castellaro, M. y otros, “Hacia la Ingeniería de Software Seguro.” XV Congreso Argentino de Ciencias de la Computación, CACIC2009. Argentina. (2009).

Solinas, M., “Elicitación y trazabilidad de requerimientos utilizando patrones de seguridad.”

Universidad Nacional de La Plata.

Argentina.

(2012).

Available in http://sedici.unlp.edu.ar/bitstream/handle/10915/421/Documento_completo.pdf?sequence=1.

Garvin, D., “What does product quality really mean?” Sloan Management Review, Vol 26, No 1. (1984).

Romaniz, S. y otros, “La seguridad como aspecto organizacional y transversal en proyectos de Sistemas de Información.” 38 Jornadas Argentinas de Informática 38JAIIO. Argentina. (2009).

Schumacher, M. et al., “Security Patterns: Integrating Security and Systems Engineering.” John Willey & Sons Inc. EEEUU. (2006).

Coplien, J.: “Design Pattern Definition - Software Patterns.” Available in http://www.hillside.net/component/content/article/50-patterns/222-design-pattern-definition.

Schumacher, M.: “Security engineering with patterns-origins, theoretical model, and new applications.” Springer-Verlag. (2003).

Alexander, C.: “The Timeless Way of Building.” Oxford University Press. EEUU. (1979).

Yoshioka, N. et al.: “A survey on security patterns.” Progress in Informatics. (2008).

Fernandez, E. et al. “Classifying Security Patterns.” Progress in WWW Research and Development Volume 4976. (2008).

Washizaki, H. et al. “Improving the Classification of Security Patterns.” 20th International Workshop on Database and Expert Systems Application, DEXA’09. Austria. (2009).

Buschmann, F. et al. “Pattern-Oriented Software Architecture: A System of Patterns.”

Chichester, UK: Wiley, 1996.

Schumacher, M. et al., “Security engineering with patterns.” Proceedings of the Conference on Pattern Languages of Programs, pp. 1–17. (2001).

Bunke, M. et al. “Organizating Security Patterns Related to Security and Pattern Recognition Requirements.” International Journal on Advances in Security, vol 5 no 1 & 2 (2012).

Kienzle, D.: “Security Patterns Template and Tutorial version 1.0.” (2008). Available in http://www.scrypt.net/~celer/securitypatterns/template%20and%20tutorial.pdf Blakley, B. et al. “Security Design Patterns.” The Open Group. (2004). Available in https://www2.opengroup.org/ogsys/catalog/g031.

Henninger, V. et al. “Software pattern communities: Current practices and challenges.”

Proceedings of the Conference on Pattern Languages of Programs PLOP. New York, NY, USA. ACM, 2007, pp. 14:1–14:19.

Darrell M. Kienzle et al. "Security Patterns Repository Version 1.0.” Available in http://www.scrypt.net/~celer/securitypatterns/repository.pdf

1501

Analizador de Intents en Android Joaqu´ın Erario, Christian Rovera, Francisco Bavera Departamento de Computaci´ on Universidad Nacional de R´ı o Cuarto R´ıo Cuarto, Argentina pancho@dc.exa.unrc.edu.ar

Resumen Existen numerosos reportes de vulnerabilidades detectadas en el sistema operativo Android. Si bien muchas de estas vulnerabilidades fueron solucionadas r´ apidamente, se detect´ o una, que hasta la fecha, no ha sido solucionada: vulnerabilidades por el uso de “Intent” expl´ıcitos.

Un “Intent” expl´ıcito es un m´etodo que puede ser utilizado en aplicaciones Android para invocar desde una aplicaci´ on a otra aplicaci´ on o servicio determinado expl´ıcitamente. Esta invocaci´ on puede incluir el paso de alg´ un tipo de informaci´ on (posiblemente sensible o confidencial). Esta forma de invocar Intents puede ocasionar una vulnerabilidad, ya que, la aplicaci´ on o servicio que se invoca puede ser modificada (de forma maliciosa o no) y esta modificaci´ on puede permitir manipular de manera indeseada la informaci´ on recibida. Por ejemplo, una aplicaci´ on que env´ıa un intent que agregue un contacto de la agenda o un mensaje para publicar en una red social y la aplicaci´ on de destino no es la esperada se puede filtrar informaci´ on sensible o confidencial sin el consentimiento del usuario. En este trabajo se presenta una herramienta para garantizar que esta vulnerabilidad no pueda ser explotada. El enfoque utilizado segue los lineamientos de la t´ecnica conocida como integridad de control de flujo.

Palabras Clave: Integridad de Control de Flujo, Seguridad, Verificaci´ on, Lenguajes, Programas.

1.

Introducci´ on

En los u ´ltimos a˜ nos, el sistema operativo Android, inicialmente pensado para tel´efonos m´oviles, fue creciendo cada vez m´as en cuanto a popularidad debido a una de sus mejores caracter´ısticas: la libertad.

Es que Android es un sistema operativo completamente libre. Es decir, no hay que pagar absolutamente nada ni para programar en el ni para poder instalarlo en un tel´efono. Lo que lo hace muy popular entre desarrolladores, que deben pagar muy poco para lanzar una aplicaci´on, y fabricantes de celulares, que ahorran a la hora de elegir el sistema operativo para el tel´efono que quieren lanzar al mercado.

1502

Otra de las ventajas de ser un sistema operativo libre es que cualquier persona puede descargar el c´odigo fuente, inspeccionarlo, modificarlo y finalmente compilarlo. Por lo que, como cualquier software libre, es m´as f´acil detectar errores r´apidamente y por ende solucionarlos, esto favorece mucho a la seguridad en el sistema operativo ya que las vulnerabilidades que van surgiendo se van reparando constantemente. Sin embargo, hay ciertos aspectos en cuanto a seguridad, que a pesar de esto, a´ un no han sido cubiertos. Y esta fue nuestra motivaci´on para llevar a cabo este trabajo: Poder solucionar alguna de estas fallas de seguridad a nivel aplicaci´on que a la fecha a´ un no han sido solucionadas.

Existen reportes de numerosas cantidades de vulnerabilidades detectadas en el sistema operativo Android, pero como se mencion´o anteriormente, al ser un sistema de c´odigo libre, estas vulnerabilidades son solucionadas rapidamente luego de ser reportadas. Aunque se encontr´o una que hasta la fecha, no ha sido solucionada: Vulnerabilidades al usar “Intent” expl´ıcitos.

Brevemente, un “Intent” es un m´etodo que pueden ser utilizados en aplicaciones Android para invocar desde una aplicaci´on a otra. Esta invocaci´on puede incluir el paso de alg´ un tipo de informaci´on y puede ser de manera impl´ıcita o expl´ıcita. En la forma impl´ıcita,el programador no indica que aplicaci´on en concreto quiere invocar sino que simplemente indica el tipo de informaci´on que quiere que sea procesada y el sistema operativo se encarga de elegir las aplicaciones correctas para que luego el usuario opte por la que desee. Por otro lado, en la forma explicita, el programador indica espec´ıficamente que aplicaci´on invocar.

Esta segunda forma de hacer el Intent puede ocasionar una vulnerabilidad, ya que, la aplicaci´on que se invoca (aplicaci´on destino) puede ser modificada (de forma maliciosa o no) y esta modificaci´on puede permitir manipular de manera indeseada la informaci´on recibida. Por ejemplo, si tenemos una aplicaci´on que env´ıa un intent que agregue un contacto de la agenda o un mensaje para publicar en una red social y la aplicaci´on de destino no es la esperada se puede filtrar informaci´on confidencial.

A continucaci´on se presenta una breve introducci´on a Android, seguido de una descripci´on de algunas vulnerabilidades reportadas. Luego, se describe brevemente la t´ecnica que motiv´o este trabajo: Integridad de Control de Flujo. Seguido de la presentaci´on de la herramienta. Para finalizar se presentan las conclusiones.

1503

2.

Android

Android es un sistema operativo basado en Linux, dise˜ nado principalmente para dispositivos m´oviles con pantalla t´actil como por ejemplo tablets y smarthphones. Fue desarrollado por Android Inc. con el respaldo econ´omico de Google que en el 2005 termina comprando a la empresa.

Finalmente, en octubre del 2008 se vendi´o por primera vez un celular con este sistema operativo.

2.1.

Arquitectura de Android

Los componentes principales de Android son cinco: Aplicaciones: Este primer componente o nivel, esta compuesto por el conjunto de todas las aplicaciones instaladas en una m´aquina Android y deben correr en la m´aquina virtual Dalvik para “garantizar” la seguridad del sistema. Generalmente las aplicaciones Android est´an escritas en Java aunque tambi´en se pueden programar en C++ utilizando el kit de desarrollo Android NDK (Native Development Kit).

Marco de trabajo de aplicaciones: Los desarrolladores tienen acceso a los mismos APIs del framework que usan las aplicaciones base (sensores, barra de notificaciones, servicios, etc...). Esta capa est´a dise˜ nada para simplificar la reutilizaci´on de componentes. Cualquier aplicaci´on puede publicar sus capacidades y cualquier otra aplicaci´on puede luego hacer uso de estas (respetando siempre las reglas de seguridad del framework). Este mismo mecanismo permite que los componentes sean reemplazados por el usuario.

Bibliotecas nativas: Android incluye adem´as un conjunto de librer´ıas de C/C++ que son usadas por varios componentes del sistema. Y son expuestas tambi´en a los desarrolladores por medio del marco de trabajo de aplicaciones. Se pueden destacar bibliotecas como: System C library, Media Framework, etc..

Runtime de Android (M´aquina Virtual Dalvik): Debido a las limitaciones de memoria y procesador de los dispositivos m´oviles donde ha de correr Android no fue posible utilizar la m´aquina virtual est´andar de Java para la ejecuci´on de aplicaciones, Google debi´o crear una nueva m´aquina virtual Dalvik que funcione mejor ante estas limitaciones.

Algunas caracter´ısticas de la m´aquina virtual Dalvik que ayudan a optimizar recursos son: • Ejecuta ficheros Dalvik ejecutables (ficheros con extensi´on .dex).

Este formato est´a optimizador para ahorrar memoria.

1504

• Basado en registros, en lugar de estar basada en una pila.

• Cada aplicaci´on corre en su propio proceso Linux con su propia instancia de la m´aquina.

• Delega al kernel de Linux algunas funciones como threading y el manejo de la memoria a bajo nivel.

N´ ucleo Linux: El n´ ucleo de Android est´a formado por el sistema operativo Linux. Esta capa proporciona servicios como la seguridad, el manejo de la memoria, el multiproceso, la pila de protocolos y el soporte de drivers para dispositivos. Es la u ´nica capa dependiente del hardware ya que act´ ua como capa de abstracci´on entre el hardware y la pila de protocolos.

2.2.

Aplicaciones

Las aplicaciones de Android, como ya mencionamos, se pueden programar tanto en C++ como en Java. Cuando se compilan los programas, el Kit de Desarrollo nos arma un archivo .APK. Los programas compilados son programas en Bytecode para la m´aquina virtual Dalvik.

Los archivos .APK son los que nos permiten instalar una aplicaci´on en el celular. Contienen una serie de instrucciones a ejecutar y adem´as otros recursos como im´agenes, sonidos y archivos .xml c´omo por ejemplo el AndroidManifest.xml.

Cada APK se asocia a un proceso u ´nico, que proporciona el ambiente de ejecuci´on de los componentes. De los cuales, uno es el componente inicial del programa.

Cuando se ejecuta una aplicaci´on se le asigna un proceso Linux y un u ´nico hilo de ejecuci´on (thread), as´ı todos sus componentes corren sobre el mismo proceso y thread.

2.3.

Seguridad en Android

La seguridad es un aspecto clave en cualquier sistema. Si nos descargamos una aplicaci´on maliciosa a nuestro celular, esta podr´ıa robarnos contactos, enviar sms por su propia cuenta y sin nuestra autorizaci´on o hasta incluso saber donde estamos posicionados f´ısicamente utilizando datos del gps del sistema.

Android propone un esquema de seguridad para proteger a los usuarios, sin tener que imponer un sistema centralizado en alguna empresa (como si lo hace el sistema operativo de iPhone por ejemplo). Este esquema esta basado en tres pilares fundamentales: la seguridad de Linux, la firma digital de la aplicaci´on y un modelo de permisos de acceso a partes del

1505

sistema. Este u ´ltimo componente establece que muchas decisiones importantes relativas a la seguridad recaigan en el usuario final.

Seguridad Linux Como se coment´o en la secci´on anterior, Android est´a basado en Linux, por lo tanto, se aprovecha la seguridad que incorpora este sistema operativo. De esta manera Android puede impedir que las aplicaciones tengan acceso directo al hardware o interfieran con recursos de otras aplicaciones.

Firma digital de las aplicaciones Las aplicaciones deben ser firmadas con un certificado digital que identifique al autor. Esto nos permite ver que aplicaciones se supone que sean m´as confiables que otras. Adem´as, la firma digital nos garantiza que los archivos de una aplicaci´on no han sido modificados. Si se opta por modificar la aplicaci´on, est´a deber´a ser firmada nuevamente. Generalmente este certificado digital no es firmado por alguna autoridad de certificaci´on.

Modelo de permisos: Android Manifest Si queremos que una aplicaci´on tenga acceso a partes del sistema que pueden comprometer la seguridad del sistema necesitamos utilizar un modelo de permisos, de forma el usuario puede conocer los riesgos antes de instalar la aplicaci´on. Para lograr esto, se utiliza el archivo Android Manifest.

Cada aplicaci´on de Android debe contener un archivo AndroidManifest.xml (con exactamente este nombre) en su directorio ra´ız. Este archivo le presenta informaci´on esencial sobre la aplicaci´on al sistema operativo, informaci´on que el sistema debe tener antes de poder correr el c´odigo de la misma.Entre otras cosas, el AndroidManifest.xml tiene: El nombre del paquete Java que sirve como identificador u ´nico para las aplicaciones del sistema operativo.

Componentes de la aplicaci´on.

Permisos que la aplicaci´on va a solicitar al momento de su instalaci´on.

Pueden ser tanto como para acceder a la API o interactuar con otras aplicaciones.

Bibliotecas con las que debe linkear.

Nivel m´ınimo de la API de Android requerido para su funcionamiento.

2.4.

Vulnerabilidad por Intent Expl´ıcitos

La interacci´on entre componentes en un sistema Android est´an dados por pasaje de mensajes llamados Intents. Estos mensajes est´an formados

1506

por una direcci´on o nombre de destino e informaci´on relacionada con la acci´on a ejecutar.

Cuando un componente env´ıa un Intent, el receptor del mismo iniciar´a una actividad, mensaje broadcast o servicio que ejecutar´an una acci´on.

Hay dos tipos de intents posibles, por un lado tenemos los intents impl´ıcitos donde no se indica el destino del mensaje, sino que solo se indica el tipo de mensaje (texto plano por ejemplo) y entonces todas las aplicaciones que declaren en su AndroidManifest que pueden recibir ese tipo de mensajes, aparecer´an en una lista para que el usuario decida que aplicaci´on es la que recibir´a el mensaje. Un claro ejemplo de esto, es cuando tenemos m´as de un navegador web instalado en el celular y hacemos click en alg´ un link que nos lleve a una direcci´on web. En ese momento, nos aparecer´a una lista con todos los navegadores instalados de la cual debemos elegir cu´al queremos usar.

Por otro lado, tenemos los intents expl´ıcitos, aquellos a los que si queremos indicarle espec´ıficamente a qui´en va dirigido el mensaje, es decir, el nombre del paquete de la aplicaci´on receptora.

La posible vulnerabilidad de este tipo de intents, radica en que al indicar solo el nombre del paquete de la aplicaci´on, es posible cambiar la aplicaci´on receptora por otra con el mismo nombre y cuyo comportamiento no es el que nosotros deseamos.

Para entender mejor esta vulnerabilidad veamos un simple ejemplo: dada una agenda de contactos que posee la funcionalidad de enviarle los contactos favoritos a otra aplicaci´on de mensajer´ıa (Similar a aplicaciones como Viber o Whatsapp). Esta aplicaci´on de mensajer´ıa, recibe los contactos de esta nueva agenda y los utiliza para poder enviarle y recibir mensajes de ellos.El problema esta en qu´e si se cambia esta aplicaci´on de mensajer´ıa, puede ocurrir que en lugar de recibir los contactos y guardarlos para luego poder comunicarse con ellos, los envi´e a una direcci´on de correo y as´ı nos robe los contactos de la agenda.

3.

Integridad del control de flujo

Las computadoras con frecuencia son objeto de ataques externos que apuntan a controlar el comportamiento de alg´ un software. Generalmente estos ataques llegan como datos a trav´es de un canal de comunicaci´on normal y, una vez que residen en la memoria del programa, explotan defectos preexistentes en el software. Explotando dichos defectos, el atacante desestabiliza y toma control del comportamiento del software. Por ejemplo, un desbordamiento del buffer en una aplicaci´on puede resultar en una

1507

llamada a una funci´on sensible del software, posiblemente una funci´on que la aplicaci´on no fue dise˜ nada para su uso.

Las pol´ıticas de la integridad de control de flujo [9,10] dictan que la ejecuci´on del software deben seguir un camino de su grafo de control de flujo creado de antemano. El grafo en cuesti´on puede ser definido por an´alisis de c´odigo, an´alisis de los ejecutables o mediante perfiles de ejecuci´on.

Hay varias formas de llevar dicho control, pero en el presente trabajo nos centraremos en la instrumentaci´on de c´odigo debido a que es el m´etodo utilizado en nuestra herramienta.

3.1.

Instrumentaci´ on de c´ odigo

La instrumentaci´on de c´odigo es la inserci´on de c´odigo con el fin de asegurar la perfomance de un sistema, diagnosticar errores y escribir informaci´on del flujo del programa. La instrumentaci´on le otorga a un programa la de incorporar: Seguimiento de c´odigo: recibiendo mensajes informativos acerca de la ejecuci´on de una aplicaci´on en tiempo de ejecuci´on.

Depuraci´on y un estructurado manejo de excepciones: b´ usqueda y correcci´on de errores de programaci´on en una aplicaci´on bajo desarrollo.

Profiling: un medio por el cual los comportamientos din´amicos de los programas pueden ser medidos durante un ejecuci´on de prueba con una entrada representativa. Esto es u ´til para probar propiedades de un programa que no puede ser analizadas est´aticamente con suficiente precisi´on, como por ejemplo an´alisis de aliasing.

Contadores de rendimiento: componentes que permiten el seguimiento de la performance de una aplicaci´on.

Registro de datos: componentes que permiten el registro y seguimiento de la mayor´ıa de los eventos en la ejecuci´on de la aplicaci´on.

4.

La Herramienta

Teniendo en cuenta la vulnerabilidad explicada en la secci´on anterior sobre los intents expl´ıcitos, se decidi´o crear una herramienta que pudiera de alguna forma solucionar este posible problema en las aplicaciones.

La herramienta tiene la funcionalidad de controlar que el flujo de la informaci´on mediante intents sea el requerido por el usuario. Para eso se introduce en la aplicaci´on que env´ıa la informaci´on, antes de cada invocaci´on de intent, una verificaci´on para garantizar que efectivamente el mensaje sea atrapado por la aplicaci´on deseada.

1508

Para lograr esto se trabaj´o sobre el control de flujo de la aplicaci´on, m´as precisamente se instrument´o c´odigo a la aplicaci´on que env´ıa el intent. A grandes rasgos, este c´odigo es una funci´on que toma como par´ametro el nombre de una aplicaci´on y un identificador u ´nico (id) de la misma. Este id es obtenida calculando un c´odigo hash para luego checkear en una lista confiable presente en el celular si el id de esa aplicaci´on es el mismo que el id actual de la aplicaci´on con ese nombre. De esta forma se detecta si el receptor del mensaje fue modificado o no.

La herramienta y su documentaci´on esta disponible en https://sourceforge.net/projects/ 4.1.

El Proceso

A continuaci´on se detalla el proceso realizado por la herramienta para generar las verificaciones. Este proceso se realiza cuando la aplicaci´on es instalada en el dispositivo Android.

Conversi´ on a c´ odigo Jasmin En primer lugar, cuando el usuario elige el programa que desea verificar que sus intents sean correctos, la herramienta transforma el archivo .APK (el programa a instalar en el dispositivo) a c´odigo Jasmin [6] (una representaci´on intermedia de c´odigo bytecode), para eso invoca una serie de scripts (basados en la herramienta Dex2Jar [3]: d2j-dex2jar.sh: Extrae el classes.dex del apk y lo convierte en un archivo .jar. d2j-asm-verify.sh: Verifica que el .jar creado sea correcto. d2j-jar2jasmin.sh: Transforma el c´odigo .jar en c´odigo Jasmin.

Obtenci´ on de la Id de la aplicaci´ on Para poder controlar que la aplicaci´on receptora del mensaje o intent no sea modificada es necesario asignarle una id u ´nica. Para esto se cre´o un script en Python que obtiene el c´odigo hash de un archivo, de esta forma se le obtiene el hash al archivo instalador (.apk) de la aplicaci´on receptora que si recibe un m´ınimo cambio entonces su id cambiar´a. Para obtener el c´odigo hash del .apk se utiliza la librer´ıa hashlib de Python.

Inserci´ on de las Verificaciones Din´ amicas Se introducen las verificaciones din´amicas que chequean que el id de cada aplicaci´on en tiempo de instalaci´on se correspondan con el id de la aplicaci´on en tiempo de ejecuci´on. Estas verificaciones se introducen en el c´odigo Jasmin.

1509

Para esto se implement´o un m´etodo Check en Jasmin que toma como par´ametros el nombre de la aplicaci´on que se va a checkear y el id o c´odigo hash del mismo que espera. Luego busca en un archivo auxiliar instalado en el dispositivo donde se encuentran los nombres de las aplicaci´on instaladas con nuestra herramienta y su c´odigo hash actual, que si el nombre de la aplicaci´on pasada como par´ametro coincide con alguno del archivo, sus ids tambi´en deben coincidir.

Figura 1. Instrumentaci´ on de c´ odigo en el archivo principal

Finalmente se introduce antes de cada invocaci´on a un intent que se desea controlar la llamada a esta funci´on. En pseudoc´odigo, es una simple llamada a la funci´on check: check(nombrePaquete,IdEsperado).

1510

Figura 2. Script insertcheckers.sh: Instrumentaci´ on de c´ odigo en el resto de los archivos que invocan a la aplicaci´ on receptora

Reconstrucci´ on del .APK Una vez finalizada la inserci´on de c´odigo solo resta reconstruir el .APK para ello se utilizan algunos scripts de la herramienta Dex2Jar: 1. d2j-jasmin2jar.sh: Reconstruye el .jar.

2. d2j-asm-verify.sh: Nuevamente se verifica que el .jar sea correcto.

3. d2j-jar2dex.sh: Se reconvierte a c´odigo dex.

Posteriormente se crea una copia de seguridad del .apk y se le reemplaza el dex original con el modificado.

Por u ´ltimo, como Android necesita que los .apk est´en firmados para que te los permita instalar, se vuelven a firmar.

La Verificaci´ on El proceso de verificaci´on en tiempo de ejecuci´on, es decir, la verificaci´on cuando se ejecuta la aplicaci´on es sencilla. El c´odigo instrumentado ejecuta un m´etodo qie verifica si el id actual del intent impl´ıcito que se ejecutar´a a continuaci´on es igual al id en tiempo de instalaci´on. En caso de no coincidir no se permite la ejecuci´on del intent.

4.2.

Ejemplos

En primer lugar se implement´o una agenda de contactos donde se almacenan n´ umeros telef´onicos que pueden ser usadas por otra aplicaciones

1511

para el env´ıo de mensajes.

Si seleccionamos un contacto de la agenda, autom´aticamente este se lo env´ıa a la aplicaci´on de mensajer´ıa qui´en almacena el n´ umero y luego de que se escriba el mensaje, env´ıa su contenido al destinatario.

Como segundo ejemplo se implement´o una aplicaci´on de logueo a homebanking de distintos bancos. La aplicaci´on permite ingresar usuario y contrase˜ na y elegir a que banco se desea acceder para luego enviar al modulo del banco seleccionado los datos de sesi´on y consultar saldo o movimientos. Este m´odulo podr´ıa ser modificado para que los datos del cliente se env´ıen ocultamente por email, o directamente que se hagan transferencias no deseadas.

Con estas dos aplicaciones se pudo apreciar que el enfoque es factible para reforzar la integridad de control de flujo en aplicaciones Android con la herramienta presentada. En abos casos se detect´o cuando las aplicaciones fueron cambiadas y/o modificadas.

5.

Conclusiones

El desarrollo de esta herramienta se puede fundamentar f´acilmente revisando las vulnerabilidades que est´an presentes actualmente en el sistema operativo Android y en la presunci´on (fundamentada en la experiencia hasta el momento) de que se detectar´an nuevas vulnerabilidades en el futuro. Por ejemplo, es posible escalar privilegios y modificar una aplicaci´on, que se encuentre presente en el celular, receptora de alg´ un intent o mensaje expl´ıcito. Tambi´en puede ocurrir que la aplicaci´on sea modificada por una actualizaci´on de la aplicaci´on (una actualizaci´on que implique un cambio defuncionalidad no deseado).

La herramienta presentada permite controlar por fuera del sistema operativo y darle m´as garant´ıa a los programadores de Android, de manera aut´omatica, verificando que los intent tengan el destinatario esperado.

En otras palabras, la herramienta garantiza la integridad del control de flujo relacionada con los intents implicitos.

La soluci´on presentada en el presente trabajo tiene la desventaja que no es una soluci´on a nivel sistema operativo por lo que se necesita s´ı o s´ı de la herramienta realizada. Esta desventaja no es tan negativa por el hecho de que son escasas las veces que se requieren realizar este tipo de checkeos por lo que no es tan molesto tener que recurrir a la herramienta para lograrlo. Adem´as necesita tambi´en de otra base confiable, en este caso de un instalador de aplicaciones alternativos que vaya actualizando y agregando los ids de las aplicaciones instaladas en un archivo

1512

confiable. Por otro lado, la herramienta tiene la ventaja que se puede modificar f´acilmente o incluso utilizarla para realizar otro tipo de chequeos o modificaciones de las aplicaciones.

5.1.

Trabajos futuros

Los trabajos m´as relevantes que se deben realizar para mejorar la herramienta y extender su funcionalidad son: extender el m´etodo de verificaci´on para incluir los intent impl´ıcitos.

En Android cuando se hace un intent impl´ıcito se crea una lista de aplicaciones que pueden manejar el tipo de dato enviado (por ejemplo, texto plano) para que el usuario elija la aplicaci´on que reciba el intent.

Para garantizar la aplicaci´on/es autorizadas a recibir determinado intent impl´ıcito es necesario poder generar la lista din´amicamente (y no tomar la lista generada aut´omaticamente por Android).

La herramienta esta programada en bash de Linux y en Python ambos estan disponibles para Android, por lo que es factible hacerla nativa para Android. Sin embargo habr´ıa que modificar o sustituir el instalador de aplicaciones de Android por un instalador “seguro” para darle mayor grado de confiabilidad.

Es necesario estudiar la posibilidad de implementar este enfoque para garantizar la integridad del control de flujo desde el receptor de los intent. Es decir, que el receptor sea el que verifique si el intent fue disparado por una aplicaci´on autorizada.

Referencias 1. Web oficial de desarrollo para Android, http://developer.android.com/index.html 2. Android Argentina, http://androidargentina.com.ar/ 3. Web oficial de Dex2jar, http://code.google.com/p/dex2jar/ ´ es Android?, http://www.xatakandroid.com/sistema-operativo/que-es4. ¿Que android.

5. Wikipedia: Android, http://es.wikipedia.org/wiki/Android 6. Web de Jasmin, http://jasmin.sourceforge.net/about.html 7. Android Security, https://source.android.com/tech/security/ 8. Introduction to Instrumentation and Tracing http://msdn.microsoft.com/en-us/library/aa983649 %28VS.71 %29.aspx ´ 9. Mart´ın Abadi; Mihai Budiu; Ulfar Erlingsson y Jay Ligatti. Control-Flow Integrity Principles, Implementations, and Applications. ACM Journal Vol V, Febrero 2007. ´ szl Szekeres; Step10. Chao Zhang; Tao Wei; Zhaofeng Chen; Lei Duan; La hen McCamant; Dawn Song y Wei Zou. Practical Control Flow Integrity & Randomization for Binary Executables.

1513

Declarado de InterĂŠs Municipal por el Honorable Concejo Deliberante del Partido de General Pueyrredon