7

Auditoría de seguridad de modelado para la

tarjeta inteligente PLANES DE PAGO CON
UML-SEC

Ene Jurjens *
Computación de la Universidad de

Oxford GB Laboratorio

http://www.jurjens.de/jan

jan@comlab.ox.ac.uk

Resumen Para superar las dificultades de diseño de sistemas de seguridad correcta, se proponen modelos formales utilizando el

lenguaje de modelado orientado a objetos UML. Específicamente, consideramos que el problema de la responsabilidad a

través de la auditoría.

Explicamos nuestro método en el ejemplo de una parte de las especificaciones comunes Electronic Purse
(CEPS), un candidato a un estándar internacional de monedero electrónico, indicar posibles vulnerabilidades y
consejos de seguridad presentes concreta en ese sistema.

1. INTRODUCCIÓN
El diseño de sistemas seguros correctamente es difícil. Muchos defectos se han encontrado en los sistemas

propuestos críticos para la seguridad y protocolos, a veces años después de su publicación (por ejemplo, [Low96]). Esto

motiva el uso de conceptos formales y herramientas desarrolladas para el diseño de sistemas para asegurar el

cumplimiento de los requisitos de seguridad.

En este trabajo nos concentramos en responsabilidad y la aplicación de política de auditoría, que proporciona los
requisitos para el mantenimiento de registros.
El Lenguaje de Modelado Unificado (UML) [RJB99] es un lenguaje estándar de la industria para la
especificación de sistemas de software. Siguiendo [Jür01c], se utiliza un núcleo formales simplificada de UML
(para los que [Jü01c] dio una extensión con la seguridad

* Apoyado por el Studienstiftung des deutschen Volkes y el Laboratorio Computing.

94 Tercera parte de la tarjeta inteligente

primitivas llamadas UMLsec) extendidos para modelar e investigar una parte crítico para la seguridad de las
especificaciones comunes Electronic Purse (CEPS) [CEP00]. CEPS es un candidato para un estándar de monedero
electrónico interoperables a nivel mundial y es apoyado por organizaciones (incluyendo Visa International) que
representan el 90 por ciento de las tarjetas monedero electrónico del mundo, por lo que su seguridad un objetivo
importante.
Un objetivo más general de esta línea de investigación se inició en [Jür01c, Jür01d] es utilizar UML para encapsular el

conocimiento en la ingeniería de seguridad prudente y por lo tanto hacer que esté disponible para los desarrolladores no

especializados en la seguridad.

En el siguiente apartado se presentan algunos antecedentes y se refieren a trabajos relacionados. En la

sección 3, damos una visión general sobre las especificaciones comunes monedero electrónico, especifique
la parte en cuestión, explicar el modelo de amenaza a la seguridad y dar resultados. Terminamos con una
conclusión e indicar planeado seguir trabajando.

1.1. SEGURIDAD seguridad en el uso de modelos

FORMAL
Ha habido una amplia investigación en el uso de modelos formales para verificar sistemas seguros.
Algunos ejemplos son [BAN89, Low96, Pau98, Jür00, AJ01, Jür01a, WW01], para una visión general WRT.
protocolos de seguridad cf. [GSG99, RSG + 01]. Sin embargo, no parece haber sido considerada
ampliamente auditoría.
Una visión general de los sistemas de pago se da en [AJSW00]. protocolos de tarjetas inteligentes han
sido invierten igated uso de la lógica formal en [ABKL93]. [BCG + 00] considera el flujo de información
segura entre los applets en un multi-aplicación de tarjeta inteligente. Una parte diferente de la CEPS se
investiga en [JW01] utilizando

Mientras que muchos estudios de casos consideran los protocolos de seguridad de la literatura académica (por lo general

se presenta en una forma mucho más manejable), un ejemplo notable de una verificación de un sistema de pago con tarjeta

inteligente utilizada en la práctica se puede encontrar en [And99]. También, [SCW00] da una demostración detallada y formal de

un producto de tarjetas inteligentes para el comercio electrónico.

sistemas orientados a objetos ofrecen un marco muy adecuado para considerar la seguridad debido a su
el modelado orientado a objetos), siguiendo [Jür01c]. la CASE-herramienta A UTO F OCU S.
encapsulación y modularización principios [Eck95, BdVFS98, Sam00]. En [OvS94] los autores formulan una
taxonomía para la seguridad en bases de datos oiented a objetos. Un modelo de flujo de datos orientado a
objetos para seguridad de la tarjeta inteligente se da en [GHdJF96].

2. El modelado de objetos-orientados a la seguridad

Utilizamos un fragmento simplificada del lenguaje de modelado UML visual (el estándar de la industria en
Modelado de auditoría de seguridad de la tarjeta inteligente con los Esquemas de pago UMLsec 95

UML se compone de varios tipos de diagramas que describen diferentes puntos de vista sobre un sistema. Aquí nos

concentramos en el uso de la notación UML para especificar los requisitos de seguridad en los mecanismos de auditoría

de un sistema.

Utilizamos los siguientes dos tipos de diagramas:

Los diagramas de clases definir la estructura estática del sistema: clases con atributos
y operaciones / señales y las relaciones entre las clases. Las usamos para especificar cómo los
objetos pueden comunicarse.

diagramas statechart dar el comportamiento dinámico de un objeto individual: in-

eventos de venta pueden causar Estado en acciones (de salida) o el cambio. A continuación vamos a definir

la sintaxis abstracta (simplificado) para estos dos tipos de diagramas (en la que el razonamiento formal se basa). Más

tarde también utilizaremos la notación diagramática habitual para facilitar la lectura.

Se define el tipo de datos Exp de mensajes criptográficos que se pueden intercambiar entre los objetos.
Asumimos un conjunto re de valores de datos básicos. El conjunto
Exp contiene las expresiones definidas inductivamente por la gramática

E :: = expresión
valor de los datos ( re ∈ RE)

llave ( K ∈ ∈ Llaves )
X variable ( X ∈ var)
( mi 1, . . . , mi n) cifrado de concatenación ( K ∈ Llaves ∪ var)
Enc ( K, E)
Dic ( K, E) descifrado ( K ∈ Llaves ∪ var)
Mac ( K, E) MAC ( K ∈ Llaves ∪ var)
Ver ( K, E) d K verificar MAC ( K ∈ Llaves ∪ var)

La parte de los CEPS considerados aquí utiliza el cifrado simétrico. Como de costumbre, asumimos las
ecuaciones Dic( K, Enc ( K, E)) = E y Ver ( K, Mac ( K, E)) = E
y se supone que no hay ecuaciones, excepto las que se derivan estos mantienen unidos.

2.1. Los diagramas de clases

En primer lugar, damos la definición de modelos de clase. Un atribuir especificación A = ( att_name,

att_type) está dada por un nombre
att_name y un tipo de att_tags.
Un especificación de operación O = ( op_name, Argumentos op_type) está dada por un nombre op_name, un
conjunto de argumentos, y el tipo de op_type del valor de retorno. Tenga en cuenta que el conjunto de
argumentos puede estar vacío, y que el tipo de retorno puede ser el tipo Ø vacía denota ausencia de un valor de
retorno. Un argumento A = ( arg_name, ARG_TYPE) está dada por su nombre arg_name y su tipo ARG_TYPE.

UNA especificación de señales es como una especificación de operación, excepto que no hay ningún tipo de retorno.
96 Tercera parte de la tarjeta inteligente

Un interfaz de I = ( int_name, Operaciones, Señales) está dada por un nombre

ink_name y conjuntos de nombres de operación operaciones y nombres de señales señales

especificando las operaciones y señales que pueden ser llamados resp. enviado a través de él.
UNA modelo de clase C = ( class_name, estereotipos, AttSpecs, especificaciones de operación, SigSpecs, Interfaces) está

dada por un nombre nombre de la clase, un conjunto de (estereotipos para nuestros propósitos actuales, esto puede estar vacío o

contener el estereotipo « Iniciar sesión »), Un conjunto de especificaciones de atributo AttSpecs, un conjunto de especificaciones

de operación especificaciones de operación,

un conjunto de especificaciones de la señal SigSpecs y un conjunto de interfaces de clase Interfaces.

UNA diagrama de clase D = ( Cls, Dependencias) a continuación, está dada por un conjunto cls de modelos de
clase y un conjunto de Dependencias. UNA dependencia es una tupla ( cliente, proveedor, interfaz, estereotipo) que
consiste en nombres de clase cliente y proveedor ( significando que cliente depende de proveedor), un nombre de
interfaz interfaz ( dando a la interfaz de la clase proveedor a través del cual cliente accesos proveedor; si el acceso es
directo este campo contiene el cliente nombre) y una estereotipo lo que para nuestros propósitos actuales serán "enviar".
Es necesario que los nombres de los modelos de clase son distintos entre sí.

En la notación diagramática (cf. Figura 1), un modelo de clase está representada por un rectángulo con tres
compartimentos de dar su nombre, sus atributos y sus operaciones (ya que todos los valores son de tipo Exp, la
información de tipo se omite en los diagramas que figuran en este documento para facilitar la lectura).

Los objetos concurrenctly ejecutados se comunican de forma asíncrona por medio de señales que
intercambian, posiblemente con argumentos. flechas de dependencia marcados con « enviar »De una clase do a
una clase DO' indicar que (una instancia de objeto de) do
puede enviar una señal a (un objeto de) DO'. Si la flecha apunta a una interfaz de
C'( representado por un círculo unido a la rectángulo clase), do sólo podrá utilizar la señal que aparece en
la especificación de interfaz correspondiente (el rectángulo respectivo marcado « interfaz »). Por ejemplo,
en la Figura 1 Tarjeta puede enviar la señal
Obstruir con argumentos dt, LDA, m, nt, bal, s 2 a CardLog, y Editor puede enviar
RespL con argumentos ceps, ISS, LDA, s 2 a LSAM ( pero no las otras señales ofrecidas por el LSAM,
ya que están reservados para Tarjeta).

2.2. Statechart ESQUEMAS

Fijamos un conjunto var de variables (a máquina) x, y, z,. . . utilizado en los diagramas statechart. Se define la noción de

un diagrama de estado para un modelo de clase dada DO: UNA

diagrama de estado S = ( Estados, init_state, Transitions) está dada por un conjunto de

Unidos ( que incluye el estado inicial init_state) y un conjunto de Transiciones.
UNA transición statechart t = ( fuente, caso, guardia, acciones, objetivo) está dada por una fuente estado, un término

operación op_term, una Guardia, una lista de Comportamiento y una objetivo estado. aquí una evento es el nombre de una

operación o de la señal con una lista de variables distintas como argumentos que se supone que es bien

mecanografiada-(por ejemplo,

op ( x, y, z)). Dejar que el conjunto asignaciones consistirá en todas las funciones parciales que asignan
Modelado de auditoría de seguridad de la tarjeta inteligente con los Esquemas de pago UMLsec
97

para cada variable y cada atributo de la clase do un valor de su tipo (parcialidad surge del hecho de que
las variables pueden no definido). UNA Guardia es una función
g: Traspaso → bool la evaluación de cada asignación a un valor booleano. Un
acción puede ser o bien asignar un valor v a un atributo una ( escrito a: = v) , llamar a una operación op resp. para
enviar una señal sig con los valores v, . . . , v 1 norte
(escrito
op ( v, 1. . . , v) resp.
norte sig ( v, . . . , 1
v)), o para devolver
norte valores v, . . , v 1 norte como son-
SPUE a una llamada anterior de la operación op ( escrito regreso op ( v,1 . . . , v)). Ennorte
cada caso, los valores pueden ser constantes, variables o atributos (y deben estar bien mecanografiada-). En
el caso de (acciones de salida llamar a una operación o el envío de una señal) se incluyen los tipos de los
argumentos (y posiblemente del valor de retorno).
Para razonar formalmente sobre gráficos de estado, [Jür01c] da una semántica de comportamiento formales (que

tiene que ser omitidos aquí).

En la notación diagramática (cf. por ejemplo, Figura 2), los estados en un statechart están representadas por

rectángulos, donde el estado inicial tiene una transición entrante desde el marcador de inicio (un círculo completo). Como

se especifica en la sintaxis abstracta, las transiciones entre los estados pueden realizar tres tipos de información como las

etiquetas:

Eventos son los nombres de las operaciones previstas por la clase en conjunto con el argumento

las variables (por ejemplo, Respi (ic, cep, ex, NT, s 1) en la Figura 2). Si otro objeto envía una
señal, la transición correspondiente se activa, y las variables están obligados a los argumentos
dados. Si una variable ya se ha asignado un valor en un punto anterior en la ejecución de la
máquina de estado, la transición sólo se ejecuta si el partido dos valores (es decir, una igualdad
implícita condicional se aplica).

guardias son condicionales escritas entre corchetes (por ejemplo,

[Ver ( K YO , s 2) = ( bal, cep,, ISS, NT, s 1) Λ. . .] en la Figura 3). Una transición sólo puede activarse si se cumplen
todos los protectores de etiquetado. A veces, un guardia implica una variable que no se le ha asignado un
valor antes (por ejemplo, como un argumento de un evento de entrada). Como en nuestros semántica formal
de comportamiento que implícitamente cuantificar sobre variables libres, esto significa que la ecuación

cesionarios el valor correspondiente a la variable libre y para aclarar esto escribimos la ecuación a
continuación como “: =” (pero formalmente no hay diferencia a la habitual “=”). Un ejemplo es [ ml:
= Mac( r, (ic, cep, nt, LDA, M, S 1))] en la Figura 2. Nótese que esto es diferente de una acción que
asigna un valor a un atributo; las variables aquí son locales al diagrama de estado y son
meramente medios sintácticos para describir el comportamiento del objeto.

Comportamiento son los nombres de las operaciones previstas por otras clases, escritas con una

precedente barra invertida e incluyendo argumentos (por ejemplo \ Init (dt, LDA, m)
en la Figura 2). Si se dispara una transición, todas las acciones de etiquetado se ejecutan, lo que significa que
los objetos que suministran las operaciones se denominan con los argumentos respectivos.
98 Tercera parte de la tarjeta inteligente

Por ejemplo, en la Figura 4, la transición de En eso a Carga se dispara cuando la señal Carga se envía y se cumplen

determinadas condiciones de validez. A continuación, a su vez la señal de RespL

se ha enviado.

2.3. Los sistemas de modelado

Estamos modelo de un sistema de S por un diagrama de clases re y un conjunto de diagramas statechart

S, uno para cada objeto. En general, también utilizamos diagramas de despliegue por ejemplo, para distinguir seguro
de enlaces de comunicación inseguras [Jür01c]. Omitimos estas aquí porque todos los enlaces entre los
participantes en la transacción de carga CEPS considerados a continuación son inseguros.

Esbozamos brevemente cómo interpretar formalmente tales modelos de sistemas (para más detalles véase
[Jür01c]). Al interpretar un modelo de sistema S, cada operación, digamos
op, la comunicación a lo largo de una dependencia inseguro se sustituye por una operación
op_out ( para las acciones) resp. op_in ( para eventos). un adversario UNA es una máquina de estados con acciones op_in
y eventos op_out ( para cada operación op en S la comunicación no segura). Sólo se consideran adversarios que
están delimitadas computacionalmente en el sentido de que pueden cifrar o descifrar mensajes sólo cuando está en
posesión de la clave correspondiente (para una formalización de este concepto véase [Jür01b]).

Los valores de salida se almacenan temporalmente sin preservar el orden de los mensajes (es decir,
tampones son multi-juegos). Los valores sin transición especificado en un objeto se ignoran. En ambos
supuestos se sigue el punto de vista UML habitual.
historias son secuencias de estados de todas las máquinas de estado correspondientes a los objetos, y los
contenidos de tampón (donde las máquinas de estado de los objetos especificados se derivan de los diagramas
statechart como se define en [Jür01c]).
Dado un modelo de sistema de S y un adversario UNA, la ejecución de S en presencia de A se da como el
conjunto de historias posibles.

Una historia es una historia posible si

en su primer componente todos los estados son estados inicial y la memoria intermedia está vacía,

y si

para cada norte ≥ 0 y cada modelo de clase do ∈ cls ∪ { UNA} que cambia de estado en el momento norte, hay una

transición t C, n desde su estado en norte a su estado en n + 1 tal que para dado norte el conjunto múltiple de eventos

(de entrada) ε norte correspondiente a las transiciones ( t C, n: do ∈ cls} está contenido en el contenido del buffer segundo norte

norte y segundo n + 1 = ( segundo n \ ε n) ∪ UNA n ( para el conjunto múltiple UNA norte de (salida) las acciones disparadas por

las transiciones { t C, n: do ∈ Cls}).

2.4. REVISIÓN DE CUENTAS

Incorporamos la auditoría en nuestro marco mediante la especificación de un subconjunto Auditoría ⊆ cls

de modelos de clase se utiliza para almacenar los datos de auditoría.

Modelado de auditoría de seguridad de la tarjeta inteligente con los Esquemas de pago UMLsec
99

Para completar damos la siguiente definición general de auditoría segura. Tenga en cuenta que la definición
sólo se aplica a la situación en la que todos los objetos en el modelo del sistema son honestos. Así, en las
consideraciones sobre CEPS continuación necesitamos nociones más específicas de auditoría segura.

definición 1 Un modelo de sistema S proporciona auditoría segura si, en presencia de cualquier adversario, los valores de los

atributos correspondientes de todos los objetos de auditoría coinciden cuando todos los objetos han alcanzado un estado final.

Tenga en cuenta que aquí no tenemos en cuenta la cuestión de si un objeto se puede mantener de alcanzar
su estado final.

3. CEPS

Damos una visión general sobre las especificaciones comunes monedero electrónico. Se han propuesto las tarjetas

inteligentes de valor almacenado ( “monederos electrónicos”) para permitir-caja libre de punto de venta (POS)

transacciones que ofrece más protección contra el fraude de tarjetas de crédito: Su chip incorporado puede realizar

operaciones criptográficas que permite la autenticación de transacciones de ruedas (mientras que los números de

tarjetas de crédito son válidos hasta que se detuvo la tarjeta, lo que permite el mal uso). La tarjeta contiene un saldo de

cuenta que se ajusta al cargar la tarjeta o la compra de bienes.

Las especificaciones comunes monedero electrónico (CEPS) definen requisitos de un sistema de monedero

electrónico interoperables a nivel mundial que proporciona la responsabilidad y la capacidad de auditoría. Las

especificaciones describen la seguridad general del sistema, la certificación y la migración. Para más detalles sobre la

funcionalidad de CEPS cf. [CEP00].

Aquí consideramos una parte central de CEPS, la (, no enlazado a base de efectivo) transacción de carga,
que permite que el titular de la tarjeta para cargar valor electrónico en una tarjeta a cambio de dinero en efectivo
en un dispositivo de carga que pertenece a la adquirente carga. Los participantes implicados en el protocolo de
transacción son la tarjeta del cliente, el dispositivo de carga y el emisor de la tarjeta. El dispositivo de carga
contiene un módulo de aplicación de la carga de seguridad (LSAM) que se utiliza para almacenar y procesar datos
(y se supone que es resistente a la manipulación). Durante la operación, el saldo de la cuenta de la tarjeta se
incrementa, y la cantidad se registra en el LSAM y se envía al emisor para la liquidación financiera más tarde entre
el adquirente de carga y el emisor de la tarjeta.

3.1. ESPECIFICACIÓN DE CEPS LOAD

TRANSACTION
Le damos una especificación de la operación de carga CEPS (ligeramente simplificado omitiendo detalles

seguridad irrelevante, y también dejando de lado los detalles necesarios para el procesamiento de excepciones y

declinó cargas). operaciones de carga en CEPS son las transacciones en línea utilizando criptografía simétrica para la

autenticación. Sólo tenemos en cuenta la carga no enlazados (donde el titular de la tarjeta paga en efectivo en una

(posiblemente unat-
100 Tercera parte de la tarjeta inteligente

Figura 1 Diagrama de clases para la transacción de carga

Figura 2 Statechart para LSAM

tendido) máquina de carga y recibe un crédito correspondiente en la tarjeta) ya que la carga ligada (donde los
fondos se transfieren por ejemplo, de una cuenta bancaria) ofrecer menos posibilidades de fraude [CEP00, Funct.
Req. pag. 12]. Utilizamos diagrama diagramas de clases y statechart introducidas anteriormente.

En primer lugar, que damos a las clases involucradas y sus dependencias en el diagrama de clases en la figura 1.

Para los participantes del protocolo, tenemos las clases Tarjeta, LSAM, y Editor. Además, cada una de las tres clases

tiene una clase asociada utilizada para los datos de registro de transacciones (marcado con el estereotipo << Iniciar

sesión >>).
Se especifica el comportamiento de las clases Tarjeta, LSAM, y Emisor usando gráficos de estado UML en
las figuras restantes.
Modelado de auditoría de seguridad de la tarjeta inteligente con los Esquemas de pago UMLsec
101

figura 3 Statechart para la tarjeta

El LSAM (Figura 2) inicia la transacción después de la tarjeta CEP se inserta en el dispositivo de carga, mediante el

envío del mensaje “Init para la carga” En eso con argumentos la fecha de la transacción y el tiempo dt, el identificador de

dispositivo de carga lda y la cantidad de la transacción m ( que es la cantidad de dinero en efectivo pagado en el dispositivo

de carga por el titular de la tarjeta que se supone que se va a cargar en la tarjeta). Cada vez que la tarjeta (Figura 3) recibe

este mensaje después de haber sido insertado en el dispositivo de carga, se envía de nuevo el mensaje “Init para la

respuesta de carga” Respl a la LSAM, con argumentos el identificador de emisor de la tarjeta ic ( como se almacena en la

tarjeta), el identificador de tarjeta cep, el equilibrio (antes de cargar) bal, la fecha de caducidad de la tarjeta ex, número de

transacción de la tarjeta Nuevo Testamento

única de la transacción, y la tarjeta MAC s 1. s 1 se compone de los valores ex, bal, dt, cep, ic, LDA, m y Nuevo
-1 compartido
Testamento, todos los cuales están firmados con la clave K do
entre una tarjeta particular y el emisor de la tarjeta correspondiente. El LSAM envía al emisor del
mensaje de “solicitud de carga” Carga con argumentos bal, ex, dt, cep, ic, LDA, m, nt, rn, s 1, Enc ( K LI, r),
y ml. rn es el número de referencia asignado por el LSAM a la transacción. Enc ( K LI, r) es la encriptación
de un número aleatorio r generada por LSAM bajo una clave K LI compartida entre el LSAM y el emisor.
ml es la dirección MAC de los siguientes datos utilizando la clave fresca

r generada por el LSAM: ic, cep, nt, LDA, m, y s 1. El emisor (Figura 4) comprueba si ic es un identificador de
emisor válido, cep un identificador de tarjeta válida y la fecha de caducidad ex no ha sido superado. El emisor
verifica si s 1 es un MAC válido genera a partir de los valores ex, bal, dt, cep, ic, LDA, m y Nuevo Testamento con
la tecla K CI
(Es decir, si Ver ( K CI, s 1) = ( bal, ex, dt, cep, ic, LDA, m, nt)). Las recupera emisor r
desde Enc ( K LI, r) ( usando la tecla K LI compartida entre el LSAM y el emisor,
es decir r: = Dic( K LI , R)) y comprueba si ml es un MAC válido de los valores ic, cep, nt, LDA, m, y s 1 mediante la
tecla r, es decir, si ve r ( ml, r) = (Ic, cep, nt, LDA, M, S 1, HC) .
Por último, el emisor comprueba que la clave K LI en realidad es compartida con el nombre LSAM LDA ( escribimos
esto como Compartido( K LI) = lda suponiendo una función Compartido
102
Tercera parte de la tarjeta inteligente

Figura 4 Statechart para Emisor

que asigna a las teclas LSAMs). Si todas estas comprobaciones tienen éxito (que en la Figura 4 se
abrevian por el condicional Issuercheck), el emisor envía el “responder a cargar” mensaje RespL con
argumentos cep, ic, LDA, rn, y s 2 a la LSAM.
s 2 consta de los siguientes valores, firmado con la clave K CI: bal, cep, ISS, NT,
y s 1.
A continuación, el LSAM envía el mensaje de “crédito para la carga” Crédito con el argumento

s 2 a la tarjeta. Por último, la tarjeta (en la verificación exitosa de s 2) responde enviando la “respuesta al crédito
para cargar” mensaje RespC con el argumento s 3 de nuevo a la LSAM. s 3 consta de los siguientes valores,
firmado con la clave K CI: bal, dt, cep, ic, nt, LDA, m, y Nuevo Testamento. La tarjeta también envía el mensaje
de registro Obstruir
al objeto CardLog, con argumentos dt, LDA, m, nt, bal, y s 2. Por último, el LSAM envía al emisor del
“mensaje de finalización de la transacción” Comp con argumentos cep, ic, LDA, m, y Nuevo Testamento. Además,
el LSAM envía el mensaje de registro
LLOG al objeto LSAMLog, con argumentos dt, cep, ISS, m, nt, y bal.
Al recibir la messsage Comp Del LSAM (y siempre que los valores contenidos coinciden con los valores
correspondientes comunicados anteriormente), el emisor envía el mensaje de registro ILOG al objeto IssuerLog,
con argumentos dt, cep, LDA,
m, nt, y bal.
Los objetos de registro simplemente toman los argumentos de sus operaciones y actualizar sus atributos en

consecuencia.

3.2. SEGURIDAD modelo de amenaza

Nos cuenta la situación de amenaza para la operación de carga y derivamos las condiciones de seguridad de
auditoría. La suposición general es que la tarjeta, el LSAM y el módulo de seguridad del emisor de la tarjeta son
resistente a la manipulación (en particular que la
Modelado de auditoría de seguridad de la tarjeta inteligente con los Esquemas de pago UMLsec 103

claves secretas contenidos no se pueden recuperar). El protocolo puede ser atacado, por ejemplo, mediante la inserción de

adaptadores o relés entre el LSAM y el dispositivo de tarjeta de carga o mediante la interceptación de la comunicación con

el emisor de la tarjeta.

Nos concentramos en el adquirente de carga como un posible atacante de la transacción. El titular de la tarjeta
podría tratar de atacar el protocolo mediante la interrupción que, por ejemplo, tirando de la tarjeta (por lo tanto hay
que asegurarse de que el dinero no se devuelve al titular de la tarjeta después de la tarjeta se ha cargado) o podría
intentar duplicar el dinero cargado cargándolo en dos tarjetas simultáneamente utilizando un adaptador (a un
dispositivo de carga sin vigilancia). No consideramos que este tipo de ataques aquí. Además, el emisor de la tarjeta
no es tan interesante como atacante, ya que controla el plan de asentamiento que se realiza después de las
transacciones, por lo que el titular de la tarjeta y el adquirente carga de tener que confiar en ella a un cierto grado de
todos modos (y mis disputas tendría que ser instalado en Corte).

Dados los participantes del protocolo, el adquirente de carga puede atacar o bien el titular de la tarjeta, u otro
adquirente de carga, o el emisor de la tarjeta, con el objetivo, ya sea para mantener la cantidad pagada por el titular
de la tarjeta (y no tener que pasarlo a la entidad emisora ), o dar crédito a una tarjeta de propiedad del mismo
adquirente de carga sin tener que pagar ningún dinero al emisor de la tarjeta.

Consideramos que los ataques contra el titular de la tarjeta. Las tarjetas inteligentes no pueden
comunicarse directamente con el titular de la tarjeta. Por lo tanto existe la amenaza usual que un dispositivo de
carga (posiblemente pertenecientes a un adquirente carga corrupto) es manipulado de manera que la
transacción se lleva a cabo como si el titular de la tarjeta sólo se había pagado parte de la cantidad que
realmente se pagó, o que la transacción no se realizado en absoluto. A continuación, el adquirente de la carga
no tendría que pagar la cantidad al emisor de la tarjeta. Sin embargo, se supone que el titular de la tarjeta
puede verificar después de la transacción, si la cantidad correcta se ha cargado (posiblemente usando un
lector de tarjetas portátil), y que un plan de asentamiento queja se asienta cualquier disputa que surja de este
tipo de ataques. El correcto funcionamiento del sistema de liquidación se basa en el hecho de que el titular de
la tarjeta sólo se debe llevar a creer (por ejemplo, probar este uso de la tarjeta - de lo contrario el adquirente
carga primero podía dar crédito a la tarjeta con la cantidad correcta, pero más tarde en el proceso de solución
reclamo que el titular de la tarjeta trató de falsificar la transacción. Por lo tanto tenemos que comprobar las
siguientes condiciones de seguridad de auditoría sobre los atributos de CardLog después Tarjeta ha alcanzado
su estado final:

Monto correcto: s 2 y s 1 verificar correctamente (por ejemplo Ver ( K CI, CardLog. s 2) = ( bal 'cep', ISS,
NT', S1' ) y Ver ( K CI, s 1' ) = ( bal "ex", dt "cep", ic "lda", m "nt" ) para algunos valores bal', bal" ,.. .) ,

y, además, tenemos CardLog. m = m"( es decir, la cantidad correcta se registra).

Un adquirente de carga también podría tratar de atacar el protocolo con el fin de hacerse pasar por otro
adquirente de carga para el propósito del proceso de liquidación, a fin de no
104 Tercera parte de la tarjeta inteligente

para pagar el importe pagado por el titular de la tarjeta con el emisor de la tarjeta. Para evitar esto, tenemos que

garantizar la seguridad de auditoría siguiente condición:

Sin mascarada: Tenemos Compartido( K LI, IssuerLog. LDA).

ml se supone para proporcionar una garantía de que el adquirente de carga debe el monto de la
transacción al emisor de la tarjeta [CEP00, Funct.spec. , 6.6.1.6]. Para poder hacer uso de esta garantía, el
emisor de la tarjeta tiene que ser capaz de demostrar que su posesión de la garantía implica que el
adquirente de carga le debe la cantidad (y que el emisor de la tarjeta no podía producir ml él mismo). Así
tenemos que la auditoría funcionalidad condición

funcionalidad garantía adquirente: Si

IssuerLog. ml = Mac( IssuerLog. r, (ic 'cep', nt 'lda', m', s 1' , hl '))

entonces el LSAM lda' ha recibido metro'.

Además, nos gustaría asegurar que esta garantía se da siempre, es decir, que se cumple la siguiente
condición de seguridad de auditoría (a la inversa de la condición funcionalidad arriba):

garantizar la seguridad adquirente: Si las máquinas de estado de la tarjeta y emisores de tarjetas

han alcanzado el estado final y CardLog. m = m' entonces

IssuerLog. ml = Mac( IssurerLog. r, (ic 'cep', nt 'lda', m' s 1' , hl '))

Tenga en cuenta que la condición previa de que la tarjeta y el emisor de la tarjeta han alcanzado sus estados finales

es necesario. En particular, si el dispositivo de carga simplemente toma el dinero insertado sin tomar ninguna acción

adicional, el titular de la tarjeta no tiene ninguna prueba de esto (pero esto es el riesgo de costumbre tomada en

máquinas de compra automáticas), y si la LDA no completa su última acción, el procesamiento de excepciones en el

lado del emisor de la tarjeta tendría que ser seguido (no se considera aquí).

3 .3 . RESULTADOS

Teorema 1 funcionalidad garantía adquirente no se proporciona en el esquema propuesto.

La razón de esto es que la seguridad de los elementos de datos en ml solamente están protegidos por
el valor aleatorio r, que a su vez se comunica encryted bajo la clave secreta K LI compartida entre el
adquirente de carga y emisor de la tarjeta. Esto significa que el emisor de la tarjeta en principio sería
capaz de fabricar ml y r
sí misma. Por lo tanto la posesión de ml no es suficiente para que el emisor sea capaz de demostrar que el
adquirente de carga fabricado ml.
Esto no es una amenaza grave, ya que sería de esperar que en situaciones prácticas cualquier disputa que surja
de esto podría ser resuelto en un proceso de liquidación. Sin embargo,
Modelado de auditoría de seguridad de la tarjeta inteligente con los Esquemas de pago UMLsec
105

el CEPS explícitamente postular este requisito. Esto debe tampoco ser aclarado, o el elemento de datos ml
ser cambiado para incluir una firma con una clave privada del adquirente carga.

teorema 2 Las condiciones de seguridad de auditoría cantidad correcta, no la mascarada,

y garantizar la seguridad adquirente se cumplen.

La prueba formal de este teorema tiene que ser omitido por las limitaciones de espacio y será incluida en la
versión larga del papel. La prueba procede inductivamente en la línea de ideas en [Pau98] y utiliza los
resultados en [Jür01b, Jür01a]. Aquí sólo podemos dar algunas observaciones informales:

Monto correcto: En esencia, hay que demostrar que la clave K CI BE- compartida
interpolar la tarjeta y el emisor de la tarjeta de seguridad establecido de extremo a extremo entre la tarjeta y el

emisor.

Sin mascarada: Esto equivale a que muestra que el identificador de dispositivo de carga, como se

almacenado en el registro emisor, corrsponds al dispositivo de carga con la que el emisor comparte la
tecla K LI.

garantizar la seguridad adquirente: Aquí hay que demostrar que la integridad de la

la información que pasa entre la tarjeta y el emisor de la tarjeta se conserva.

4. CONCLUSIÓN Y TRABAJO FUTURO

Hemos investigado la seguridad de las especificaciones actualmente desarrollados comunes Electronic
Purse (CEPS) utilizando el lenguaje de modelado orientado a objetos UML. Beneficios de nuestro enfoque
incluyen la posibilidad de investigar la seguridad en el contexto del desarrollo general del sistema. Desde
violaciónes de seguridad a menudo se producen en los límites entre los mecanismos de seguridad (tales
como protocolos) y el sistema general [And94], esto es muy útil. Elegimos UML entre los diversos lenguajes
de modelado orientado a objetos, ya que es el actual estándar de facto de la industria y por lo tanto muchos
desarrolladores será capaz de tomar ventaja de una extensión de UML mediante primitivas de seguridad.

Aparte de estas ventajas metodológicas, este trabajo ofrece resultados concretos sobre la seguridad de
los sistemas de pago que van a ser elaborado y realizado de acuerdo con el CEPS. Nuestra investigación
mostró una debilidad que surge del hecho de que el emisor de la tarjeta no obtiene una prueba de sonido de
la transacción desde el adquirente carga. Como es habitual, los resultados positivos que se dan aquí no debe
interpretarse que demuestren los CEPS seguro (así conocido, tal prueba es imposible).

Debido a las limitaciones de espacio que sólo se podía considerar una parte de las especificaciones del CEP, las
otras partes se dejan para el trabajo posterior. Desde UML ofrece una variedad de mecanismos de modelado con
diferentes grados de abstracción, teniendo en cuenta una gran parte de un sistema parece relativamente factible.
También puede ser interesante
106 Tercera parte de la tarjeta inteligente

considerar la reevaluación de la seguridad después de los cambios del sistema. Además, vamos a ampliar este enfoque más allá

del razonamiento acerca de la rendición de cuentas.

Expresiones de gratitud

Esta idea de utilizar UML para especificar las propiedades de seguridad surgió cuando se hace consultoría de seguridad

para un proyecto durante una visita de investigación con M. Abadi en los Laboratorios Bell (Lucent Tech.), Palo Alto, cuya

hospitalidad se agradece. Comentarios o consejos de los participantes del curso de verano “Fundamentos del Análisis y

Diseño 2000 seguridad” y el seminario “Seguridad a través de análisis y verificación” Dagstuhl (especialmente D. Gollmann)

se agradece, así como los comentarios útiles de G. Wimmel y la árbitros anónimos en un proyecto.

referencias

[ABKL93] M. Abadi, M. Burrows, C. Kaufman, y B. Lampson. Autenticación y delegación

con tarjetas inteligentes. Ciencia de la programación informática, 21 (2): 93-113, 1993. [AJ01] M. Abadi y Jan
Jurjens. espionaje formal y su interpretación computacional,
2001. Enviado.
[AJSW00] N. Asokan, P. Janson, M. Steiner, y M. Waidner. El estado de la técnica en electrónica
sistemas de pago. Los avances en las computadoras, 53, 2000.

[And94] R. Anderson. ¿Por qué fracasan los criptosistemas. Communications of the ACM, 37 (11): 32-40,
Noviembre de 1994.

[And99] R. Anderson. La verificación formal de un sistema de pago. En Hinchey y Mike

Jonathan Bowen, editores, Industrial-fuerza Métodos formales en la práctica, páginas 43-
52. Springer, 1999.
[BAN89] M. Burrows, M. Abadi, y R. Needham. Una lógica de autenticación. Proc. Real
Un Society de Londres, 426: 233-271, 1989. [BCG + 00] P. Bieber, J. Cazin, P. Girard, J.-L. Lanet, V Wiels, y G.
Zanon. Comprobación segura
interacciones de los applets de tarjeta inteligente. En ESORICS, 2000.

[BdVFS98] E. Bertino, S. De Capitani di Vimercati, E. Ferrari, y P. Samarati. Excepción-

control de flujo de información basado en los sistemas orientados a objetos. ACM Transactions on Inƒormation y
seguridad del sistema, 1 (1): 26-65, 1998.
[CEP00] CEPSCO. Especificaciones monedero electrónico común, 2000. Los requisitos de negocio
vers. 7.0 Requisitos funcionales, vers. 6.3, vers especificaciones técnicas. 2,2, disponible de
http://www.cepsco.com.
[CFMS94] S. Castano, M. Fugini, G. Martella, y P. Samarati. Seguridad base de datos. Addison
Wesley, 1994.
[Eck95] C. Eckert. Coincidencia de las políticas de seguridad a las necesidades de aplicación. En JHP Eloff y SH
von Solms, editores, Conferencia Internacional IFIP TC11 11 sobre la Seguridad de la Información,

páginas 237-254. Chapman & Hall, 1995.

[GHdJF96] H. Glaser, P. Hartel, y E. de Jong Frz. Estructuración y la visualización de un IC - Tarjeta
estándar de seguridad. En en [HPQ96], páginas 89-110, 1996.
[GSG99] Stefanos Gritzalis, Diomidis Spinellis, y Panagiotis Georgiadis. Los protocolos de seguridad
a través de redes abiertas y sistemas distribuidos: Los métodos formales para su análisis, el diseño y la verificación, Comunicaciones
Diario ordenador, 22 (8): 695-707, 1999. [HPQ96] PH Hartel, P. Paradinas, y J. - J. Quisquater, editores. Segunda
investigación de la tarjeta inteligente
y la rueda de aplicación avanzada (CARDIS). Stichting Mathematisch Centrum, Amsterdam, 1996.
Modelado de auditoría de seguridad de la tarjeta inteligente con los Esquemas de pago UMLsec 107

[Jür00] Ene Jurjens. flujo de información segura para procesos concurrentes. En CONCUR 2000 (11ª Conferencia Internacional
sobre Teoría de concurrencia), volumen 1847 de LNCS, páginas 395-
409, Pennsylvania, 2000. Springer.
[Jür01a] Ene Jurjens. Compuestabilidad de secreto. En Taller Internacional sobre Matemática
Métodos, modelos y arquitecturas para la red de ordenadores de Seguridad (MMM-ACNS
2001), LNCS, San Petersburgo, 21-23 de mayo de 2001. Springer. [Jür01b] Ene Jurjens. El secreto de preservación de

refinamiento. En Métodos formales Europa (Internacional

Simposio), LNCS. Springer, 2001.
[Jür01c] Ene Jurjens. Hacia el desarrollo de los sistemas de seguros utilizando UMLsec. En fundamen-
Tal Enfoques de Ingeniería de Software (FASE / ETAPS, Conferencia Internacional),
LNCS. Springer, 2001.
[Jür01d] Ene Jurjens. Transformaciones para la introducción de patrones - un estudio de caso sistemas seguros.

En WTUML: Taller sobre Transformaciones en UML (2001 ETAPS satélite evento),

Genova, 7 de abril de 2001.

[JW01] Ene Jurjens y Guido Wimmel. modelado de la seguridad para el comercio electrónico: la
Especificaciones monedero electrónico comunes. Enviado de 2001.

[Low96] G. Lowe. Rompiendo y se fija el Protocolo de clave pública de Needham-Schroeder utilizando

FDR. Conceptos y herramientas de software, 17: 93-102, 1996.

[OvS94] M. Olivier y S. von Solms. Una taxonomía para bases de datos orientadas a objetos seguras. ACM
Las transacciones relativas a los sistemas de bases de datos, 19 (1): 3-46, 1994.

[Pau98] Lawrence C. Paulson. El enfoque inductivo para la verificación de protocolos criptográficos.

Diario de la seguridad informática, 6 (1-2): 85-128, 1998. [RJB99] J. Rumbaugh, I. Jacobson, y G. Booch. El
Lenguaje de Modelado Unificado de referencia
Manual. Addison-Wesley, 1999.
[RSG + 01] P. Ryan, S. Schneider, M. Goldsmith, G. Lowe, y B. Roscoe. Modelado y
El análisis de los protocolos de seguridad. Addison Wesley, 2001. (pendiente de publicación). [Sam00] P. Samarati. Control de

acceso: Las políticas, modelos, arquitecturas y mecanismos. Conferencia

Notas, 2000.
[SCW00] S. Stepney, D. Cooper, y J. Woodcock. Un monedero electrónico: Especificación, Re-
confinamiento, y la prueba. Oxford University Computing Laboratory, 2000. Técnica Monografía PRG-126
[WW01]
G. y A. Wimmel Wißpeitner. técnicas de descripción ampliada de la seguridad inge-
niería. En IFIP SEC, 2001.