Una Arquitectura Criptográfica Orientada a Objetos Genérica

Tropyc: Un Lenguaje de Patrones para Software Criptográfico
Alexandre M.Braga; Ceilia M.F.Rubira; Ricardo Dahab
State University of Campinas
Institute of Computing
P.O.Box 6176
13081-970 Campinas-SP-Brazil
Phone/fax: +55+19+7885842
e-mail:{972314,cmrubira,rdahab}@dcc.unicamp.br
1. Introducción
La criptografía moderna es ampliamente utilizada en muchas aplicaciones, tales como
procesadores de texto, hojas de cálculo, base de datos y sistemas de comercio electrónico. El
amplio uso de las técnicas criptográficas y el interés actual e investigación en arquitecturas de
software y patrones nos llevó hacia las arquitecturas de software criptográfico y patrones
criptográficos. En este trabajo, presentamos una arquitectura criptográfica orientada a objetos
genérica mas un conjunto de patrones criptográficos, basados en esa arquitectura, clasificados
de acuerdo a los objetivos de la criptografía [MvOV96] (los cuales con confidencialidad,
integridad, autenticación y no repudio, como se resumen en el Apéndice A) y organizados
como un lenguaje de patrones para software criptográfico.
Este trabajo está destinado a ingenieros de software que deben tratar con
requerimientos de seguridad, de aplicaciones orientadas a objeto, basados en criptografía,
pero que no tienen mucha experiencia en criptografía. Otro grupo de interés es aquella gente
que busca una arquitectura de software general para su software criptográfico o sus
componentes.
Este trabajo está organizado como sigue: Sección 2 propone Tropyc, un lenguaje de
patrones para software criptográfico, y un patrón que describe una arquitectura de software
genérica para aplicaciones criptográficas orientadas a objetos. La Sección 3 es una aplicación
ejemplo que utiliza el lenguaje de patrones: una herramienta para compra electrónica y
distribución en línea de documentos de hipertexto sobre Internet, llamada PayPerClick. La
Sección 4 contiene patrones relacionados a los servicios criptográficos. Los aspectos de
seguridad basados en criptografía de PayPerClick están implementados como instanciaciones
de nuestros patrones criptográficos en la Sección 5. En la Sección 6 se ofrece algunas
conclusiones y futuros trabajos. Hay una breve introducción a la criptografía en el Apéndice
A.
2. Un lenguaje de patrones para software criptográfico
En esta sección proponemos Tropyc, un lenguaje de patrones para software criptográfico.
Nuestra propuesta se enfoca en tres objetivos: (i) la definición de una Arquitectura
Criptográfica Orientada a Objetos Genérica (sus siglas en inglés – GOOCA); (ii) la
descripción de servicios criptográficos como patrones y (iii) la organización de estos patrones
criptográficos como un lenguaje de patrones. En la Tabla 2 se resumen todos los patrones, sus
focos de interés y propósitos. Tropyc tiene que ver con dos tipos de intereses tratados por
separado: aquellos que actúan sobre un servicio criptográficos específico y aquellos que
tienen que ver con la instanciación de GOOCA. Los patrones en la Sección 4 se enfocan sobre
los requerimientos y restricciones actuando sobre los servicios y sus composiciones. GOOCA
se enfoca en el segundo tipo, esto es, aquellas acciones que tienen que ver con la instanciación
y comportamiento de nuestra estructura genérica. En criptografía, los extremos de un canal de
comunicación son usualmente llamados Alice y Bob; Eve es habitualmente un adversario
escuchando en el canal.
Tabla 2: Patrones criptográficos y sus propósitos
2.1.
Resumen del Lenguaje de Patrones
Tropyc ofrece un conjunto de patrones estrechamente relacionados, soportando el
proceso de toma de decisión de tener que elegir servicios criptográficos para atacar los
requerimientos de seguridad de una aplicación y las necesidades de los usuarios. Cuando
existe una comunicación o un intercambio de archivos en línea, algunas veces, dada la gran
sensibilidad de los datos, es necesario garantizar la Confidencialidad en el tratamiento de la
información. De todos modos, la Confidencialidad a solas no garantiza que los datos no sean
modificados o reemplazados. Particularmente, en una comunicación en línea, es también
importante garantizar la Integridad de los Mensajes y la Autenticación del emisor. Hay
algunos contextos en los cuales es necesario prevenir que un entidad deniegue sus acciones o
acuerdos. Por ejemplo, alguna forma de Firma se hace necesaria cuando se compran bienes
sobre Internet. Algunas veces los requerimientos de seguridad basados en criptografía de
aplicaciones conducen a composición de servicios para proveer Confidencialidad con
Integridad, Confidencialidad con Autenticación de Emisor o Confidencialidad con Firma. La
criptografía es una gran consumidora de tiempo, de modo que la perfomance de los
algoritmos es siempre importante. Una Firma, puede ser mejorada en este aspecto, si se utiliza
una Firma con Apéndice. Por eficiencia, Confidencialidad con Firma con Apéndice es
comúnmente utilizada en lugar de Confidencialidad con Firma. Todos los aspectos abajo
detallados comparten algunos aspectos de la estructura y su comportamiento, los cuales
pueden ser abstraídos como una Arquitectura Criptográfica Orientada a Objetos Genérica
(sus siglas en inglés – GOOCA).
Figura 1: Patrones de diseño criptográfico y sus relaciones
En la Figura 1 se muestra un grafo acíclico dirigido de dependencias entre patrones. Un borde
desde el patrón A al patrón B significa que el patrón B es generado a partir del patrón A.
GOOCA genera la micro-arquitectura para los cuatro patrones básicos. Todos los otros
patrones son combinaciones de estos. De este modo, los nueve patrones criptográficos
instancian GOOCA. Un recorrido por el grafo está dirigido por dos cuestiones: Qué servicios
criptográficos deberían ser utilizados para atacar requerimientos de aplicaciones y
necesidades de los usuarios..? Y cómo deberían ser estructurados los componentes
criptográficos para obtener una fácil reutilización y mayor flexibilidad..?
2.2.
Arquitectura Criptográfica Orientada a Objetos Genérica (sus siglas en inglés –
GOOCA)
Contexto
Dos objetos, Alice y Bob, intercambiando datos mediante mensajes. Necesitan realizar
transformaciones criptográficas sobre los datos, solos o en combinación. Ellos desean
disponer de un componente criptográfico que sea flexible y que pueda ser fácilmente
reutilizable con otras transformaciones criptográficas.
Problema
Cómo diseñar una micro-arquitectura orientada a objetos para un diseño criptográfico y
facilitar la reutilización de estos componentes…?
Aplicabilidad
- Cuando se deben cumplir aspectos que se presentan muy separados entre requerimientos
criptográficos no funcionales y requerimientos funcionales de una aplicación específica.
- Cuando se debe lograr una transformación criptográfica exitosa y la aplicación a
desarrollar debe ser independiente de aquella transformación.
- Cuando es necesaria una interface genérica para varios tipos de servicios criptográficos.
Se debe cumplir con (Forces)
- Minimizar la dependencia entre los funcionalidades criptográficas y el código de la
aplicación, a fin de lograr los objetivos de reutilización.
- Incrementar la facilidad de lectura de programas con código criptográfico.
- Preservar el rendimiento de los algoritmos de transformaciones criptográficas.
Solución
Alice realiza una trasformación criptográfica sobre los datos antes de enviárselos a Bob. Bob
recibe el mensaje y realiza la transformación inversa para recuperar los datos. Alice y Bob
deben acordar la transformación a realizar y compartir o distribuir claves si fuese necesario.
En la Figura 2 se muestra el diagrama de clases que generaliza la transformación criptográfica
en un interface abstracta y distingue los roles de Emisor y Receptor a partir de los roles de
Codificador y Decodificador. GOOCA es una abstracción de alto nivel para todos los patrones
criptográficos. Todos los patrones criptográficos inician dicha estructura y su dinámica.
GOOCA tiene dos clases, Alice y Bob, que representan el “todo” de una relación de
agregación; y dos clases asociadas que representan la “parte”. Ellas son Codifier y Decodifier.
La clase Codifier tiene un método asociado f(), el cual realizar la transformación criptográfica
sobre m. La clase Decodifier tiene su método asociado g(), el cual realiza la transformación
criptográfica sobre x = f(m). La transformación y su reversa están basadas sobre el mismo
algoritmo criptográfico. En la Figura 3 se muestra el comportamiento dinámico de GOOCA.
Figura 3: Estructura de GOOCA
Figura 4: Dinámica de GOOCA
Consecuencias
- Todas las transformaciones criptográficas presentarán un comportamiento común que
podría ser generalizado en un diseño flexible.
- Las implementaciones específicas de instalaciones criptográficas podrían tener un mejor
rendimiento que las instanciaciones de GOOCA, el cual está caracterizado por inserción
de indirecciones en el código.
- Se pueden obtener mas fácilmente sistemas flexibles y adaptables, con requerimientos de
seguridad basados en criptografía, cuando los algoritmos criptográficos son desacoplados
de sus implementaciones, y a su vez éstas son desacopladas de los servicios criptográficos
que utilizan.
- Los requerimientos de seguridad basados en criptografía son generalmente requerimientos
no funcionales de aplicaciones de propósitos generales y no deberían contaminar la
funcionalidad de aquellas aplicaciones. La separación explícita de aspectos en dos tipos de
requerimientos facilita su lectura y reutilización.
Factores de implementación
-
-
-
Este patrón puede ser fácilmente adaptado para tratar con el almacenamiento y
recuperación de archivos. En esa situación, los mensajes del emisor y receptor pueden ser
reemplazados por los de almacenamiento y recuperación. También se puede obviar la
referencia a Alice y Bob.
La “Computer Reflection” puede ser utilizada para hacer explícita la distinción de
aspectos y restringir el código criptográfico a un meta-nivel, responsable de la
intercepción de la comunicación o petición de almacenamiento y encriptación de los datos
interceptados.
Antes de que la comunicación segura comience, es necesario un paso de negociación
previa para que las dos partes acuerden sobre cuál transformación será realizada y para
intercambiar información tal como claves y parámetros de algoritmos.
El rol de Eve depende de la instanciación. Básicamente, puede ser reemplazada, modificar
o insertar su propio mensaje dentro del canal de comunicación.
Ejemplo
Un sistema de pago electrónico, debido a sus fuertes requerimientos de seguridad, se diseña
mejor como una instanciación de GOOCA. Esta aplicación, llamada PayPerClick, se diseña e
implementa mas abajo.
Usos conocidos
Todos los patrones criptográficos descriptos en la Sección 4, y ampliamente utilizados en
sistemas como [HY97, Her97, CBHK98, HN98, BDR98] son instanciaciones de GOOCA.
Patrones relacionados
Al instanciar GOOCA, se pueden utilizar algunos patrones muy bien conocidos. El patrón
“Strategy” puede ser utilizado para obtener independencia del algoritmo. El patrón “Bridge”
puede ser utilizado para obtener independencia de la implementación. El patrón “Abstract
Factory” puede ser utilizado en los pasos de negociación previa para decidir cuál algoritmo o
implementación utilizar. Los patrones “Observer”, “Proxy” y “Client-Dispatcher-Receiver”
podrían ser combinados con los patrones criptográficos para ofrecer comunicaciones entre
procesos de forma transparente y segura, de manera que Alice venga a ser parte del
“Forwarder” y Bob ser incorporado dentro del “Receiver”. El patrón “State” podría ser
utilizado para proveer un comportamiento dependiente de los estados, tales como encender y
apagar la seguridad del canal. El patrón “NullObject” puede ser utilizado para diseñar un
transformación nula. El patrón “Reflection” puede ser utilizado para desacoplar la
funcionalidad de la aplicación y la funcionalidad criptográfica. Aspectos de bajo nivel de la
seguridad, tales como criptografía, pueden ser encapsulados en un “Security Access Layer”
[YB97,16].
3. PayPerClick: Un Sistema de Pago Electrónico
Figura 4: Participantes del Comercio Electrónico
A fin de ilustrar la aplicabilidad de este lenguaje de patrones, usaremos sus patrones
criptográficos en un ejemplo grande, el diseño de una aplicación de comercio electrónico.
Consideraremos únicamente los aspectos de seguridad de la aplicación, basados en
criptografía. Los patrones de la Sección 4 enfocan aspectos particulares de este ejemplo. En la
Figura 4 se muestran los tres principales entidades de una aplicación de comercio electrónico
y el flujo de dinero y datos sensibles entre ellos [AJSW97]. El Broker usualmente es una
banco o institución financiera como Visa o MasterCard. El Payee ( Vendedor ) puede ser un
proveedor de acceso a Internet y los Payers ( Compradores ) son los clientes. Los
Compradores solicitan dinero electrónico a los Brokers, los cuales pueden debitarlo de las
tarjetas de crédito de los Compradores. Luego los Compradores pueden utilizar su dinero
electrónico para comprar ( electrónicamente ) bienes en Internet. Ellos pueden solicitar
recibos, los cuales son emitidos por el Vendedor. Los Vendedores solicitan los pagos a los
Brokers, quienes pagan a los Vendedores por la venta de bienes a los clientes de los Brokers.
Habitualmente, en este tipo de operatoria, el flujo de dinero real es desde los Brokers a los
Vendedores. Dos buenas fuentes de información sobre sistemas de pago electrónico son
[FD98, HY97].
Nuestra aplicación es un herramienta para la venta electrónica y la distribución en
línea de documentos de hipertexto basados en el modelo de la Figura 4. Los documentos de
hipertexto están accesibles a través de enlaces a páginas de HTML visualizadas mediante
navegadores web. Este tipo de aplicaciones es útil para venta de libros en línea mediante
enlaces en sus índices. Aquellos clientes interesados en una sección específica de un libro
pueden comprar la información necesaria haciendo click sobre el hipertexto. A esta
herramienta la llamaremos PayPerClick [BDR98]. El patrón Composite puede ser utilizado
para calcular el valor del documento y de su huella electrónica o autenticador. Esta huella
electrónica es un MDC (ver Apéndice A.1) de un árbol específico de un hiperdocumento
utilizando una política transversal. La parte Compradora de la aplicación puede ser un applet
Java o un plug-in de Netscape, el cual se comunica con su servidor web (Vendedor o Broker).
Los Compradores usualmente tienen un monedero electrónico. Los Brokers emiten dinero
electrónico el cual puede ser dividido en un cantidad fija de monedas electrónicas, las que son
utilizadas para pagos. En las Figuras 5 y 6 se muestra cómo modelar una transacción de pago
con PayPerClick como una instanciación de GOOCA. En este diagrama se utilizan dos
patrones, Sender Authentication y Signature. El primero es usado para autenticar los pagos; el
segundo para firmar el recibo.
Figura 5: Estructura de pagos
Figura 6: Dinámica de pagos
4. Patrones de servicios criptográficos
Esta sección contiene patrones relacionados a los servicios criptográficos que dan soporte
a los objetivos criptográficos [MvOV96] (resumidos en el Apéndice A).
4.1.
Confidencialidad
Contexto
Alice desea enviar un mensaje sensible a Bob. Ella desea mantener este mensaje en secreto
para Eve, de quien Alice sospecha que puede estar intentando leer el mensaje.
Problema
Cómo puede Alice enviar un mensaje a Bob de manera tal que para Eve le sea imposible leer
su contenido..?
Aplicabilidad
- Cuando dos entidades necesitan compartir información con confidencialidad.
- Cuando es necesario desacomplar la encripción de la comunicación o almacenamiento.
Se debe cumplir con (Forces)
- El costo de encripción no debe ser mayor que el valor intrínseco del mensaje a ser
encriptado.
- Eve no puede, en ninguna situación, ganar acceso al contenido del mensaje. Este es el
principal requerimiento para el patrón.
- El costo que debe pagar Eve para romper el mensaje debe ser mucho mayor que el valor
atribuido al mensaje.
Solución
Este patrón soporta encripción y desencripción de datos. Alice y Bob previamente han
acordado en un método criptográfico y en una clave o secreto compartido (si se utiliza
criptografía de clave pública, Bob debe primero obtener la clave pública de Alice). Bob
encripta el mensaje y lo envía a Alice. Alice desencripta el mensaje encriptado y recupera el
mensaje original.
Consecuencias
- La encripción es lenta. La seguridad de la información encriptada está en la clave de
encripción y la fortaleza de un criptosistema descansa en el secreto de una clave fuerte. De
todos modos, a mayor longitud de la clave, mas lento es el algoritmo.
- Eve no puede leer el contenido del mensaje, pero ella puede siempre reemplazar o
modificar el mensaje encriptado o realizar algún otro tipo de ataque.
- Errores en la transmisión o en el dispositivo de almacenamiento pueden potencialmente
hacer imposible la recuperación del mensaje original.
Factores de implementación
- Claves secretas o privadas deben ser protegidas de copia o modificación no autorizada.
- Es necesaria una infraestructura para distribuir claves.
- Habitualmente se requiere algún tipo de detección de error para evitar pérdida de
mensajes.
- Se debe elegir el tipo de criptosistema a utilizar (de clave simétrica o secreta, de clave
pública o híbrido).
Ejemplo
Cuando en PayPerClick, un Comprador hace una petición de dinero electrónico, envía al
Broker su número de tarjeta de crédito encriptada. El Comprador encripta el número de su
tarjeta de crédito con su clave de encripción y se la envía al Broker dentro de una petición de
dinero. El Broker desencripta el número de tarjeta de crédito con su clave de desencripción y
utilizar ese número para debitar el monto de dinero solicitado.
Usos conocidos
Un uso común de este patrón es la encripción de correo electrónico [Her97].